I think this ignores the fact that an agent can be meaningfully embodied in the internet, using APIs for sensors and actuators. OpenAI's training of large language models with reinforcement learning, recent retrieval augmented models and "chain of thought" reasoning are all meaningful steps in this direction in my opinion.
Microsoft (Semantic Machines) | Senior Software Engineer | Berkeley, CA or Boston, MA or Redmond, WA or fully REMOTE | Full Time
The Semantic Machines group is bringing next-generation natural language processing (NLP) technologies to products used by hundreds of millions of people worldwide. You can learn more about how Microsoft is using this technology to create entirely new kinds of user experiences here: http://semanticmachines.com/.
At the core of our platform is a new programming language, designed to support programs structured like human commands which are predicted by machine learning models. This language includes ideas from functional and logic/constraint programming, as well as novel features for meta-computation and introspection. We’re looking for engineers to work alongside product and research teams to help guide the evolution of this platform, including improvements to the core programming language, runtime, constraint system, and tooling.
The ideal candidate should be passionate about designing and evolving programming languages and/or practical formal reasoning systems, supporting users with high quality tools, and working on a rapidly evolving product-driven platform. No experience with machine learning or natural language processing is required – we’d love to work with people who are excited about the promise of these technologies and the opportunity to make them more accessible, regardless of their previous exposure to them.
At Semantic Machines [0] we rely heavily on probabilistic programming to build state-of-the-art dialogue systems. In particular, we use a library called PNP (probabilistic neural programming) on top of Dynet to allow us to express structured prediction problems in a simple and elegant form. If there are questions I am happy to elaborate to the extent I can. (Also, we are hiring! My email is jwolfe@.)
I saved the document for later use, but it got me thinking how ORMs like hibernate is dealing with the migration and future proofing issues. I wrote code libraries for a small company, in which part of the libraries design is to allow data transformation/representation of Data Models to work on the new database schema/changes while representing the data structure as if it were from previous versions. So I ended up writing generators to create a mapping of the DAO and the Models exposed to the API's in such a way that when the database changes while you still have to support the previous version of the API, I will only have to edit/tweak the mappers of the previous version of the API.
Yep, that sounds about right. For us, API communication and some global events flow through channels into the app state, where it's distributed to components. For routing we've built up a library around secretary, where we write down a map of uris, handlers, and metadata (can be a modal, etc). Info about the current page and such goes into the app state and that drives the transitions between page components.
No, you are still free to organize your application state however you wish. For example, our app dynamically pulls in content as you browse from feed to feed and use infinite scroll. It's up to you to decide what to fetch when, and what to cache/discard as the user navigates around.
An Om question: what do you store in the app state and what do you store in component local state?
In my own application, I started off storing everything in app state, using local state only for short-lived transient data, but over time I found that having a bunch of information like what tab is currently visible in the app state became difficult to manage and made the app state a nightmare. So now I like to keep a strict separation: app state is basically my model - the data being processed (if I were writing a text editor, its the document being edited) and local state is everything else: which dialog is open, which tab is selected, button toggle state, mouse state etc (in a text editor, whether bold is selected, whether I'm in print preview mode or edit mode, etc). Basically app state is what is being processed and local state is how to process or display it. This separation also means that the app state is what gets synced with the server. I like to think of it as "if its something I might want to persist in the database, then it lives in app state, if its something I would never want in the database, then it lives in local state"
I'm curious what other peoples experience with this is.
Another Om question: how do you sync state between client and server, or how do you handle communication?
I looked at how om-sync does this (using tx-listen to automatically sync changes), but ended up building a more traditional request/response model using sente[0] and having my app ask for sub-trees of my app state as needed. Again, just wondering about peoples experience with this and different approaches tried.
We're still figuring out exactly where the boundary lies, but our current approach is much like yours -- view state that's purely local to a component goes in local state, and everything else goes in app state. This feels more natural, but means you lose some of the nice benefits of things like replay/undo for this local state.
For client/server, we've started building up some nice abstractions around our API (like fetching more data in a generic paginated list stored in a cursor), but the write side is still mostly manual. We're trying to use the same API for iOS and web, which probably prevents us from doing some fancier things that continue the same architecture back into the server.
So far, I've only made some (large-ish, granted) prototypes with Cljs and Om, but I've run into this as well. I ended up opting out of local state. I put view state and model state in the same atom, but I tried my best to keep them separate within the atom.
Easy replay/undo was one reason. Another reason was that I wanted to be able to take a _complete_ snapshot of the app state, for debugging purposes. A third was that I wanted to keep all the state that a component needs to know in order to render itself in one place, not many places.
I put viewmodel state with the app state - my app state basically is viewmodel state, ___domain state source of truth is the database really, so you need to do ajax to traverse the ___domain object graph, its not stored on the client.
Just like you want to control a react.dom.input, you also may want to control a tabstrip. Maybe you have some biz logic that says "When you click save, select the next record, and if record.type===2, select the third tab". You never know in advance what state needs to be controlled from the top, I found myself refactoring my viewmodel state higher and higher.
The mouse state is never going to be controlled from the top, so that is component local state.
It sounds like you're differentiating between model state and view model state.
I haven't used Om yet, but a potential approach could be to maintain two stateful objects: one for the model (e.g. stuff that you'd persist permanently), one for the view model (e.g. which tab is selected).
If you wanted your app to come back to exactly the same state after a page reload, you could persist the model in databases, and the view model in browser local storage.
Maybe a stupid question, but since I didn't see anything about that : what kind of database do you use, and how is it with Clojure ? React + ClojureScript seem a given for me on the interface side, especially with core.async and the other possibility, but I'm a bit more weary for the server side, and that's one of the last showstopper I have.
And, how do you go for teaching new comer on the project ? I do suppose you don't only hire Clojure or functional dev, so the transition part seem very interesting, especially with Om getting more (deserved) attention !
This is also something I'm curious about, particularly how migrations are managed within a team. Most of the solutions I've seen require writing plain SQL in migration files which you name yourself. It's simple but I miss the productivity of DjangoORM or ActiveRecord for example.
Or do most people use a schema-less database?
Most functional languages don't really go for any ORM. It's usually considered a cumbersome abstraction for relational databases. Clojure makes it really easy to use SQL directly with the java.jdbc package [1], or through some helper library like SQL Korma [2]. There are also several migrations libraries you can use [3].
It takes a bit of getting used to coming from an ORM, but you'll love the lack of overhead soon enough :)
What do your "templates" look like, and how easy they are to edit? In Montage we've kept our templates as close to plain HTML documents as possible, and the CSS experts/designers we've worked with have really appreciated how easy it is to understand.
I'm wondering if this is an issue for you (or perhaps everyone is comfortable enough with the ClojureScript/Om syntax that this isn't a problem)?
Strategically, how did you approach the rewrite? It sounds like you had a significant amount of frontend code; replacing everything at once can be risky. Did you choose specific pages and work your way in, or scrap everything and work your way from the inside out?
I'm a Javascript/Python/Ruby professional, and have made a few really swell SPA's in JS.
But my dream is to be a really good Clojure(Script) lisp programmer. I'm not so good at any lisp, but have went thru a couple of books, try to do every tutorial and to play in the LightTable instarepl and implement things that I can easily do in JS.
How can I, who am far from a lisp pro, get a job in a lisp/clojure shop? I think by doing something 8h/day in a team is the best way to learn, but of course no one will hire you if you slow down the rest (at least in the beginning).
How do you deal with propagating events through the system? If I'm clicking Follow as people are following and unfollowing, how does that number change?
Clicking follow mutates the global app data. Changes to the app data causes the entire application to re-render, and React pushes those changes out to the DOM.
So, to answer your question, we don't propagate events :)
