This is spot on. Obviously there is a lot to dislike about performance reviews, but big companies need some process to determine who gets a raise, who gets promoted, etc. Although flawed, performance reviews are the best process for that.
I think the things that companies can do to make them better are:
2. Have transparency about the ranking system and distribution to all current employees and future employees.
3. Ensure that some amount of accountability is shared at the department level and also at the team level, so you can have somewhat objective conversations about trade-offs between departments and teams.
Has anyone implemented a DSL for a professional use case? I would love anyone to share what was the use case, what alternatives did you consider and how did you measure success?
I have previously implemented one for credit policy decisions, but I am not sure in hindsight if it was the right approach and we did a poor job of measuring success, so I would love to hear from the community.
In the full, strict sense presented in the article? No. Since the publication of the book in 2010, we have a lot more serialization languages available to us, and I try to avoid creating a full, true parser for a brand new language when possible.
I've created a couple of things that can be plausibly called interesting DSLs, in the sense of having some grotesquely non-standard execution model relative to the host language, and having language-like recursive grammar constructs, but so far I've managed to keep them within YAML and/or JSON and thus didn't have to create a new language.
(Before someone pops up with "ick! YAML!", consider your options; do you want to encounter your fifth or sixth YAML format, or you want to encounter a brand new bespoke language for whatever it is I solved this way? At least you know how YAML is broken; Jerf's Bespoke Language is a minefield of "interesting" of unknown size and density, and I'm just talking in grammar... we still haven't even gotten to have it actually functions and you've already blown more limbs off than you realized you had.)
Going back even farther, the "interpreter" pattern in the GoF is extraordinarily powerful, but in 2024 I'd update it to if at all possible be written in the form of some existing serialization mechanism that then serializes straight into your AST(-equivalent) and starts off to the races from there. If you have to write a real grammar, well, there may be times that is unavoidable, but if you can avoid it, you can cut much more directly to the "meat" of your task without having to deal with bringing up a complete grammar first.
One was for a visual novel video game, where the designers had relatively detailed specs. They had been manually translating those to code, but that was tedious and pretty far outside their expertise. I was contracted to translate those specs into code. I ended up mostly writing a script to turn their specification language into a more structured representation, then translate that into code, with a bit of back & forth to make their language more precise. From everything I heard this was a big success, my script saved them a lot of hours, and the game was pretty successful by the standards of indie games.
The other...is not exactly a DSL, but I don't know what to call it. We had researchers who were writing a lot of numeric code to try and find signals in data. This code often worked, but was slow and expensive to run at large scale, in part because it would have to recalculate intermediate values over and over again. So we wrote a "DSL" that had almost exactly the same syntax as the code they were writing, but was lazy and created a DAG rather than immediately executing, and eventually used the DAG to execute much more efficiently.
I have created a DSL for supply chain optimization over the last 10 years[1], and gave a talk about it back in 2017[2] that summarizes the main reasons why we did this over the alternatives (such as using Python).
We measure success along a few indicators:
- Ease of deployment of an optimization model to production
- Training time required before a new employee (with a background in Supply Chain, but no software development experience) is proficient enough to contribute new code and edit existing code.
- Cost of running all the execution infrastructure
- Frequency of defects caused by running out of memory
- Frequency of package version upgrades that require manual intervention
- Frequency of unsuccessful attempts at auto-completion and other Language Server Protocol interactions
Depending on what you consider "professional". For a while, I was trying to create a DSL for UI designers. The idea was to give them a platform-agnostic syntax, using terminology familiar to their domain, that could be transpiled into platform-specific UI code. I've somewhat moved on from the idea, but the repo is still up - I wrote it as a tree-sitter grammar:
I've implemented a DSL for casino slot machine mathematics. I originally did it as an internal DSL with C#, but it was too difficult to use. Many of my customers solve these problems using Microsoft Excel, so a programming style environment is difficult, and embedding into an actual programming language even worse.
I then redid it as an external DSL, which has been successful, but a vast amount of work. A more limited environment has a lot of advantages for my users.
In languages with macros (esp Lisp), you can implement HTML right inside the language. It can become both a data structure that code can be embedded into and a generator of applications.
The huge number of Flask-like stacks makes me think that’s a significant, use case. Double true if the host stack supports live updates of running applications.
You might also look up the iMatix DSL’s that had high-level constructs that compiled to low-level code.
Loads. Back in 1999 I built an entire suite of DSLs for generating web applications - you described objects, properties, validation rules, newsletter settings, commerce functionality, forum rules, etc and it used some combination of compile time code generation and run time parsing to deliver the functionality, substantially decreasing the dev overhead in building "good enough" web apps.
I will also note, that while it's possible to build a parser generator for external DSLs, for many use cases concrete syntaxes with existing parsers work fine. Back in 2000 I created a set of DSLs for generating web applications and I used the concrete, serializable syntax of XML as I got the capacity to describe types fairly clearly and I didn't need to generate a parser (or more importantly, an IDE plugin with auto complete and type validation). I figured I could always write a lightweight interface to display the info from the concrete DSLs to save business users from the angle brakcets. Json would allow you to do the same these days.
Yes, Rust macro-based, used for defining process-variables for distributed control systems. We can define hierarchical identities with strong types, poll frequencies, cache TTLs, and other metadata that gets serialized and brokered. It's been quite successful (IMO).
Most of the workday application is written in an in house DSL. Certainly has it's limitations but definitely allows for some impressive feature delivery and stability.
This is a common practice in other high altitude, high traffic mountains, such as Aconcagua. Rangers actually watch you deposit your excrement bag and fine you if you do not do so or they catch you leaving your waste on the mountain. I'm frankly surprised its just now becoming a policy on Everest.
It sounds gross, but in practice it is not as bad as it seems. For anyone interested in the details, it is stored in multiple bags (one bag per movement, then multiple larger outer bags) and freezes pretty quickly, so there isn't really any smell.
" They could only get hired into new companies where nobody knew any of their past coworkers, because a simple reference check would reveal how difficult they were to work with." --> Any tips on how to effectively conduct reference checks? In my experience, candidates will only provide references from folks that they know will give glowing review, so you end up with generic positive feedback that ends up not being informative.
Would love to hear any strategies others have found successful.
I see the value in this, but I personally have not had success with it. I have found I am most effective remote if during my working hours, I don't do anything I wouldn't do if I was working at the office. For me, that means no laundry during the day, no extended lunches, etc. It keeps my mind in "work mode" and at the end of the day, I shut my office door and transition my brain out of work-mode.
I don't think its any less convenient for my partner than if I worked in an actual office. Plus, I still have the added benefit of no commute, which means more time with my partner.
Streamlit and Shiny for Python are both great for cranking out simple UI's for basic use cases, especially where there is a tie-in with something data or machine learning related.
A typical workflow could be for a team to prototype in one of these tools, get feedback, but at some point they eventually get rebuilt as a proper webapp. I would love to see these tools evolve to not require that total rebuild. Maybe they could add the capability to export to React or Angular. Then that could be used as a starting point for converting that into a proper webapp.
I think the things that companies can do to make them better are:
1. Have well established career frameworks (aka career ladders) ahead of time. These should be as detailed as possible. https://sijinjoseph.com/programmer-competency-matrix/
2. Have transparency about the ranking system and distribution to all current employees and future employees.
3. Ensure that some amount of accountability is shared at the department level and also at the team level, so you can have somewhat objective conversations about trade-offs between departments and teams.