Well, this is used in the automotive domain for long time now. Look at matlab/simulink: you can draw your algorithm as a state machine and generate the code out of it. Recently I implemented a state machine to manage a quite complex react component, who moves from one visual state to another through some css transitions. It’s not a difficult state machine, but I think people are not so well versed in it.
If I got it correctly, they created a node native module that allows synchronous communication on standard I/O between external processes.
So, this node module will make possible the communication between the typescript compiler GO process, that will expose an “API server compiler”, and a client side JavaScript process.
They don’t think it will be possible to port all APIs and some/most of them will be different than today.
I really wonder how tough that is going to be to migrate to.
I have API use that falls into a few categories, that aren' just LSP-ish type cases:
- Transforms, which presumably there has to be some solution for, even if it's porting to Go.
- Linters, which integrate with typescript-eslint and need the type-checker.
- Codemods, which create and modify AST nodes and re-emit them.
- Static analyzers, which build us app-specific models of the code and rely on AST traversal and the type-checker.
- Analyzer libraries that offer tools to other libraries and apps that expose the TypeScript AST and functions that operate on AST nodes.
Traversing the AST over IPC is going to be too chatty, so I presume there will have to be some sort of way to get a whole SourceFile in one call, but then I wonder about traversal. You'll need a visitor library on your side of the IPC at least, but that's simple. But then you also need all the predicates. You don't want to be calling ts.isTemplateExpression() on every node via IPC.
And I do all this stuff in web workers too, so whatever this IPC is has to work there.
In the post, they specifically talk about two points that seems to address some of your doubts
1. “We expect to have a more curated API that is informed by critical use-cases (e.g. linting, transforms, resolution behavior, language service embedding, etc.).”
2. “We also can imagine opportunities to optimize, use other underlying IPC strategies, and provide batch-style APIs to minimize call overhead.”
Anyway, I’ve used the compiler API a lot too, and I really enjoy its huge capabilities, making possible practically everything on the source code (EDIT: and hijack the build process too). I hope we won’t miss too much.
In Russian, Czech or Slovak, I have never ever seen or heard it being used in the context of an innocent camp. It just means bad kind of prison and sometimes military barracks - when you want to imply you don't like those military barracks.
When лагерь is used by itself, it depends on context - could be a prison/labor camp, kids summer camp, a historical military reference to an army camping on a campaign, or even a refugee camp or a tourist camp. Not that different from English “camp” really.
Russian also borrowed lager bier in “лагер” (without the softening “ь”), whereas Czech and Slovak have native words for it (ležák/ležiak) with a similar (if not greater) complexity in styles to Germany.
Nobody here calls it "Lager", u less it actually is one. We have Helles, Dunkles, Weissbier, dunkles Weisbier, Kellerbier, Pils, Lagerbier... If you order a Lager in Bavaria I honestly have no idea what you would get. Most likely still a beer, I have to try it next time, weather is nice enough for a first trip to a beer garden anyway!
You'd get a Helles or Pils, depending where in Germany you are. Either because the waiter/waitress know that they are lagers, or alternatively, they don't, but understand Bier, in which case they'll serve you a Helles or Pils as well.
I’m surprised that Kölsch is top-fermenting as I (a Dutch beer noob) would describe Kölsch as “like a regular lager, but then really nice and in a long drink glass”.
A lot of home brewers who don’t want to mess about with temperature controlling bottom fermentation go for a top fermenting Kölsch yeast to achieve the same effect.
The article talks about 90% of all consumed beers are "Lager" which definitely isn't what I would expect when I hear "Lagerbier". The "90% mainstream beer" is called Pilsner in Germany (unless you're in Bavaria where the mainstream beer is probably Hefeweizen).
PS: I'm actually surprised by the article, I thought this type of beer was first brewed in Pilsen/Plzeň (thus the name "Pilsner")
Not sure about the rest of Bavaria, but "Helles" (Lager) is the mainstream beer in Munich. Weißbier (Hefeweizen) isn't that uncommon but rather cliche...
I don't know about Swabia and Franconia but if you are in Upper Bavaria (or probably any part of Altbayern [0]) and order a beer (without specifying anything else), you will definitely get a Helles.
Nobody I know orders their beer "ein Untergärig bitte" (Switzerland here). Although not THE name, still everybody knows what a Lager is (as in, whether they want a helles or dunkles). Yes of course there's the camp meaning as well, but you wouldn't mix that up in a Kneipe. Only when you read just a random internet article and you have zero context to know which is which - even though this phrasing would be really weird if it referred to a camp (for me, non-native English speaker).
Yeah, Lager inside a Kneipe / Wirtshaus is obviously meant in the "category of beer" way. At least here in Bavaria, it would just be "ein Helles" (or "ein Dunkles"). :D
This is commercial advertising, a product description. That has of course its place but it's something different from the daily usage, which is what I meant. You wouldn't order at the Theke ein Untergäriges, or would you???
> At least here in Bavaria, it would just be "ein Helles" (or "ein Dunkles"). :D
No, I wouldn't. And you wouldn't just order "a Lager", right? I kinda think we don't actually disagree. :)
The only difference may be that, if asked what kind of beer a "Helles" is, expecting some kind of category other than "Helles", I would answer "untergäriges Bier" and you may answer "Lager". Both are correct, one description focuses on the ability to keep the beer in storage in the ice cellar of the brewery, the other on the brewing process. What we both probably don't do is also e.g. call a Pils a Lager. In my experience, some of our american friends do that.
My point was that the US definition of beers that are "Lager" is very broad, way broader than in Germany (and probably also Switzerland & Austria) and that some parts of Germany even use completly different words for a similar categorization.
Ahhh I think I finally got your point - that basically everything is confusing (as even my favorite porters can be untergärig). And I also learned that the Austrian Märzen is not exactly what I'd expect, so all in all an interesting beer thread :)
PS I wouldn't order a lager either. If I didn't care what they have (very rarely) I'd order "a beer" and live with it, or otherwise I'd ask for the choices.
In automotive, development of control algorithms for the engine is entirely “visual”, through simulink/matlab. You design the model on simulink, then it generates the C code. I don’t have direct experience outside the automotive sector, but I believe that this approach is used in other sectors like aerospace. Maybe designing models is better than writing low level code for control algorithms?
Yes, IIRC some aerospace companies also use simulink. It's popular with safety critical stuff.
> Maybe designing models is better than writing low level code for control algorithms?
If you need both the code and the model, then generating the code from the model is also much easier than proving that your handwritten C code behaves exactly like the model used for verification. Having visual control flow for complex control systems might be less error prone than manually writing C (or Rust or Zig or $flavour_of_the_day) code. You probably know that, but other folks shouldn't forget that automotive and aerospace control software often means "programming errors might result in people getting injured or worse".
In power generation control when electrical engineers are discussing or analyzing the behavior of a governor or exciter block diagrams representing transfer functions are used. I would program turbine controls primarily in function block diagrams since it a great visual representation of the algorithms that makes
It easy for some one to understand and observe how it works. I started with computer programming and it was quite an adjustment in my way of thinking to implement algorithms this way but no question it is the right tool for the job in controls.
I don't have any experience in the automotive sector. But when you say that the development of control algorithms for the engine are visual, I immediately thought finite state machine. My question: Are they finite state machines or is there more to it than that?
Depending on how complex, it would be a hybrid system. You have finite discrete states, but also continuous dynamics that need to be controlled (like a PID)
Control systems have always been designed in a connected box fashion. Before gui software existed. Visual coding is just an extension of what was being done on a blackboard
I always think to priority-based scheduling in this way. Maybe it can help someone else.
The scheduler will always schedule the highest priority task among ones in the ready queue, but at different times.
- If preemptive, the scheduler will schedule the higher priority task (higher than the currently running one) as soon as it enters the ready queue.
- If non preemptive, the scheduler will schedule the higher priority task only when the running one terminated or explicitly call a yield() (call to yield --> cooperative)
In principle, you can mix both scheduling types, making some tasks "non-preemptable" and other tasks "preemptable".
reply