I have joined MZ as a Staff Software Engineer.
I have joined A9. This blog continues to be my own.
It looks like you are researching razors. I think you are about to go off on a yak-shaving endeavor, and I cannot let you do that, Dave.
What I would really like my DWIM
agent to do. That, and to stop calling me Dave.
Being lazy and impatient, I like an idea of an IDE. The ease of things like autocompletion, refactoring, code search, and graphical debugging with evaluation are, for the lack of a better word, are good.
I like Eclipse in particular — force of habit/finger memory; after all, neurons that pray together stay together. Just like all happy families are alike, all emacs users remember the key sequence to GTFO vi (:q!) and all vi users remember the same thing for emacs (C-x C-c n) – so they can get into their favorite editor and not have to “remember”.
So, recently I thought that it would be good for a a particular DSL I am using to have an auto-completion feature (because why should I remember ). So I thought, great, I’ll maybe write an Eclipse plugin for that… Because, hey, I’ve made one before, how bad could it be?
Well, obviously I would only be solving the problem for Eclipse users of the DSL in question. And I have a suspicion I am pretty much the only one in that group. Moreover, even I would like to use some other text editor occasionally, and get the same benefit.
It seems obvious that it should be a separation of concerns, so to speak:
- Provider-side: A language/platform may expose a service for context-based auto-completion, and
- Consumer-side: An editor or shell may have a plugin system exposed to take advantage of this.
Then a little gluing is all that is required. (OK, I don’t like the “provider/consumer” terminology, but I cannot come up with anything better — I almost named them “supply-side” and “demand-side” but it evokes too much association with AdTech that it’s even worse).
And indeed, there are already examples of this.
There is a focus on an IDE paradigm of using external programs for building, code completion, and any others sorts of language semantic functionality. Most of MelnormeEclipse infrastructure is UI infrastructure, the core of a concrete IDE’s engine functionality is usually driven by language-specific external programs. (This is not a requirement though — using internal tools is easily supported as well).
- Atom defines its own API
And so I thought – wouldn’t it be good to standardize on some sort of interaction between the two in a more generic way?
And just as I thought this, I learned that the effort already exists: Language-server protocol by Microsoft.
I actually like it when an idea is validated and someone else is doing the hard work of making an OSS project out of it…
At some point I remember having a short chat with Werner Voegels about taking spot instances to extreme in a genuine market in which compute power can be traded. His response was “what about data gravity?” to which my counter was — but by making data transfer into S3 free (and, later, making true the adage about not underestimating the bandwidth of a truck full of tape) you, while understanding the gravity idea, also provide incentives to not make it an issue. As in — why don’t I make things redundant? Why don’t I just push data to multiple S3 regions and have my compute follow the sun in terms of cost? Sure, it doesn’t work on huge scale, but it just may work perfectly fine on some medium scale, and this is what we’ve used for implementing our DMP at OpenDSP.
Later on, I sort of dabbled in something in the arbitrage of cost space. I still think compute cost arbitrage will be a thing; 6fusion did some interesting work there; ClusterK got acquired by Amazon for their ability to save cost even when running heavy data-gravity workload such as EMR, and ultimately isn’t compute arbitrage just an arbitrage of electricity? But I digress. Or do I? Oh yes.
In a way, this is not really anything new — it is just another way to surface the same idea that
The following is a dramatization of actual events.
“I need access to these reports.”
“Well, here they are, in the UI.”
“But I need programmatic access.”
“We don’t have an API yet.”
“Fine, I’ll scrape this… Wait… This is Flex. Wait, let me just run Charles… Flex is talking to the back-end using AMF. So what do you mean you don’t have an API? Of course you do — it is AMF. A little PyAMF script will do the trick.”
“Please don’t show it to anyone!”
P. S. That little script was still running (in “stealth production”) months, if not years, later.
This is one of those posts that will continue to get updated periodically.
I’ve been asked to describe my software development philosophy (and variations thereof) often, so I’ll just keep this here as a list.
- The right tool for the right job. A “PHP programmer”, to me, is like a “screwdriver plumber” or a “hammer carpenter”. First, figure out the problem you are trying to solve, then, pick the tool.
- Do not reinvent the wheel.
- It is likely that others solved a similar problem. There may be solutions out there already, in the form of libraries, SaaS, FOSS or commercial offerings, etc. Those are likely to have gone through extensive testing in real life. Use them. Your case is not unique, nor are you that smart.
- You are not that smart.
- Consider buying (borrowing, cloning, licensing) rather than rolling your own
- Engineering is an art of tradeoffs. Time for space, technical debt for time to market, infrastructure costs for customer acquisition, etc.
- Abstractions leak.
- The following things are hard. However, they have been solved and tested and worked for years, if not decades. Learn to use them: