Tacton Systems | Multiple roles | Hybrid, Stockholm
Full stack Java, JavaScript / TypeScript
We make a Configure-Price-Quote SaaS for complex product portfolios. For example, one customer is Tetra Pak, that sells machines that build packaging (milk, juice, etc). These machines are like a two-story building with many variations, every aspect has to be well-defined and validated before it's ordered.
In our solution products can be modeled in detail with constraints, and during a sale options are chosen and validated, often visualized parametrically, pricing is done, and a quote is prepared. All based on the well-defined model.
It's a 30-year old company that started as a research startup, grew organically, and has a stable customer base. After a recent acquisition it's aiming to grow, therefore many positions are open. I started working here just a year ago, but I can say the work environment is healthy and relaxed, lots of competent people and everyone I interacted with so far have been very nice and professional.
No, they would make a capital infusion on paper and then make Cerebras buy more hw from that money on paper, thus showing huge revenues on Nvidia books.
Nvidia’s target is performance across concurrent users and they are likely already outperforming Cerebras there as far as costs are concerned. They have no reason to try to beat the single user performance of this.
I've seen multiple issues solved like this after engineering teams have been cut to the bone.
If the cost of maintaining enough engineers to keep systems stable for more than 24 hours, is more than the cost of doubling the container count, then this is what happens
Shouldn't be too high cost if you only run 2x the instances for a short amount of time. A reasonable use of Cloud, IMHO, if you can't figure out a less disruptive bandaid.
The generated programs are only technically Prolog programs. They use CLPFD, which makes these constraint programs. Prolog programs are quite a bit more tricky with termination issues. I wouldn’t have nitpicked if it wasn’t in the title.
Also, the experiment method has some flaws. Problems are hand-picked out of a random subset of the full set. Why not run the full set?
Most likely cherry-picking. The approach is only going to work well in domains where Prolog is commonly used to write solutions to problems, like logical puzzles or constraint problems etc.
Yeah I’m a huge proponent of this general philosophy, but after being introduced to prolog itself for a third of a semester back in undergrad I decided to stay far, far away. The vision never quite came through as clearly as it did for the other wacky languages, namely the functional family (Lisp and Haskell in my case). I believe you on the fundamental termination issues, but just basic phrasing seemed unnecessarily convoluted…
Since you seem like an expert: is there a better technology for logical/constraint programming? I loved predicate calculus in school so it seems like there should be something out there for me, but so far no dice. This seems kinda related to the widely-discussed paradigm of “Linear Programming”, but I’ve also failed to find much of interest there behind all the talk of “Management Theory” and detailed mathematical efficiency comparisons.
I guess Curry (from above) might be the go-to these days?
Curious to know what part of syntax you found convoluted. If you remember any examples I’d appreciate it.
Maybe you want a constraint programming environment instead. As example check out Conjure from St Andrews:
https://conjure.readthedocs.io/en/latest/tutorials-notebook....
More generally there are the theorem provers like Coq, etc., but their use cases are even more specific.
If I may nitpick, the call to children’s accept methods should be in the visitor, not the parent. Imagine you’re writing an XMLGeneratorVisiter. The visit method for the parent would print <parent>, call child accepts, and then print </parent>. If you do it the way it is done here you lose the control on when the children are visited.
Also, the point of the visitor pattern is not just pattern matching/polymorphism. Of course you could do it with polymorphism or conditionals or whatever. But the visitor pattern reduces coupling and increases cohesion. So you get a more maintainable, testable code base. Pattern matching with a candied switch doesn’t give you that.
Prolog was never good at the things they thought it would be at, like AI, which is better done by ML today, specifically often like you said, with NNs. But it turned out to be good for other things, and those use cases are still alive today, even though there are many competitors. Look at Tiobe index, Prolog's usage is constant just under 1 percent, and has been for decades. So it's good for something.
Prolog, and Constraint Programming especially are great to have in your toolbox. I’ve done research in the field for years, and my job in the industry today is writing Prolog. There are real issues with Prolog:
- no proper module nor package system in the modern sense.
- in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided unification guards which tackle this to a degree.
- lack of static and strong types makes it harder to write robust code. At least some strong typing would have been nice. See Mercury as an example of this.
All being said, Prolog is amazing, has a place in the future of programming, and gives you a level-up understanding of programming when you get how the types in every OO program is a Prolog program itself.
I'd advise to not use Prolog as general-purpose programming language, but as an embedded DSL or as a service for the part it's really suited for (if your app involves exploration and search over a large combinatorical space in the first place, such as in discrete optimization in industry, logistics, and finance). You really don't need yet another package manager and pointless premature modularization for modelling your business domains in optimization.
I've tried casually to take this approach and what I've found is that basically none of the Prologs out there are really designed to be properly embeddable. Even Scryer Prolog, written in Rust, isn't really set up to linked into a Rust program and run this way. I was able to "sort-of" make it happen, but it wasn't a workflow that had been optimized for.
To be clear what I'd like is to be able to fire up a thread hosting a Prolog runtime and stick predicates into it and query it using an API in the host language's syntax. Instead the best I could do was munge strings together and parse result out, sort-of. And that was after a bunch of time spent trying to reverse-engineer Scryer's API.
I would love to embed a Prolog to host my application's business rules and knowledge. I could see it super useful in a game even (think of the myriad of crazy rules and interactions and special cases in a game like Dwarf Fortress...)
Yeah the preferred approach would be to run a Prolog engine as a service and access it via usual JSON-over-HTTP/REST protocols. Has the benefit of being able to adapt and scale/provision the specific Prolog engine load as well. For smaller projects I guess you could use Minikanren which is specifically for embedding as I understand it, but even standard job shop scheduling and factory/office resource planning tasks would be better served with a Prolog (micro-/whatever) service already IMO.
The domain-specific Prolog code bases you're going to create still can become large and represent a significant development effort. Prolog being an ISO standard with many conformant (or at least mostly conformant) implementations available and relatively strong mindshare and ecosystem compared to extremely niche "CP solver packages and OR-tools" (which one exactly?) significantly reduces project risks such as not being able to find experts, the system not meeting functional or performance requirements, or becoming obsolete down the road. The same cannot be said for some mythical "CP solver packages and OR-tools"; you've nowhere to go if your "CP solver packages and OR-tools" project fails. Optimization and scheduling/planning projects, by their nature, are somewhat experimental and need exploration. It would thus be very difficult to pick "CP solver packages and OR-tools" upfront.
> extremely niche "CP solver packages and OR-tools" (which one exactly?) significantly reduces project risks such as not being able to find experts, the system not meeting functional or performance requirements, or becoming obsolete down the road. The same cannot be said for some mythical "CP solver packages and OR-tools"
"Mythical CP solver packages and OR-tools"? Lol!
Google's OR-Tools [1] has been winning golds in the MiniZinc Challenge since 2013 [2]. In 2023 it won Gold in most categories and the only Prolog to win, SICStus Prolog, took one Silver back. I'm curious where you're spending time in the community if you can word a comment like this as OR-Tools is the behemoth in this area and Prolog is the weird hacker siren call that appeals to people who certainly aren't about to publish anything novel in the space.
I say this as someone who has tinkered a lot with Prolog over the years and finds Prolog's execution model to work really well with the way I think about programming. Prolog and its hybrid solver model just isn't good enough at any one thing to make it SOTA. It's fun to tinker with, but I just don't think in 2024 it has enough to offer anyone who's not interested in the language or the WAM to make it worth exploring, especially not as an embedded constraint solver.
Ok but is the argument now just because it's by Google with its media presence it's not niche? "Constraint solving" is an overly broad term that can encompass most of computer science but at least finite domain solving, interval propagation, and SAT solving as specific algorithmic approaches with very different applications. Going by your post, potential users looking for planning, scheduling, or optimization problems to solve will jump to very specific implementation techniques having won synthetic benchmarks in basically unrelated domains for showcasing "something with constraints". Classic OR is about optimizing systems of linear (in-)equations, but discrete optimization problems and most financial investment planning problems don't come in this flavor and really need very laborious encodings (like into equational systems with 1000s of artificial variables) to fit OR model formulation requirements or SAT checkers. Great, now you're prematurely solving idiosyncratic representation problems; your consultants surely will rub their hands. But I stand by my opinion that Prolog is, by far, a much better starting point for the kind of explorative programming required in this domain. Making Prolog fast/scaling on mainstream cloud hardware (like Quantum Prolog and SICStus are doing) has very much to offer to users, and is behind many or even most real-world scheduling and optimization applications.
I agree with your point, I just would like to point out maybe the OR-tools they meant is the one made by Google, so a specific one: https://developers.google.com/optimization
OR-Tools has a lot of bindings in different languages, though Javascript/Node doesn't seem to be a first-class supported environment. Looks like https://www.npmjs.com/package/node_or_tools ports a few solver packages into Node so if those solvers fit your needs you can use this package.
To me this makes Prolog sound like a tool to reach for similar to SQL. Specialized language for asking specific kinds of search or query over your data.
Indeed Prolog programs are also called databases sometimes. Some things Prolog can do over SQL:
- infinite data defined by recursive predicates
- flexible data structures (think JSON but better, called complex terms) and a way to query them (called unification algorithm)
- execution strategy fine-tuned for reasoning (called resolution algorithm). You can do this with SQL but you’d have to formalize things using set operations and it’d be very very slow.
On the other hand, SQL can query plain data very very fast.
I've also wondered why Prolog or at least Datalog isn't available/used more widely as a query layer, especially considering that the promise of SQLs natural-ish language really didn't lead to a level of adoption among non-tech workers even approaching the popularity of the spreadsheet, so the reason for that style of syntax didn't really pan out, and Prolog would appear to have some syntactic and capability advantages.
I concur, Prolog particularly excels at being an advanced configuration, embeddable DSL that allows one to express system configurations that would otherwise be not easily possible using a bespoke configuration language or a format. I have used an embedded Prolog core to express complex installation configurations in the past with a great success, and I would do it again for the right problem space.
Maybe it's just me but I see a lack of a package manager as a massive, massive pro. I can't stand how seemingly every language has a package manager which requires it's own installation and you have to learn how to use THAT thing and then you need some library off github that does some minor task really well but you can't just download the fucking code, you have to import it via, idk, the Fork-Lyft manager which requires Python 3.3 and the PillJump framework and it's just like, I just want a fucking function to parse JSON, I don't want to saddle my system with 600 MB of shit I don't need.
You can always just download the code, nobody's forcing you to use a package manager. It just turns out that unless you want to spend most of your life building and fixing other people's code, it's much easier to use the package manager. The inefficiency is the price we pay, but it's worth it.
Me too! I absolutely see a lack of package manager as a pro. I also hate to saddle anything with 600MB I don't need. 100% agree.
I would go as far as to say that Prolog is more a problem solving language rather than a system building language. Package managers and module systems are for modularization of big systems. You don't need that when solving small recurrent problems. Furthermore, lack of them forces you to avoid dependencies, that most of the time would end as technical debt. IMHO.
Yes :) we make software that helps sell complex products (If your product has a million options and takes up a whole factory floor you can’t just have a series of dropdowns)
Thanks for the insight, Görkem! I was always thinking CPQs make a really good use case. We had so many problems with performance, not your product, CPQ is becoming a standard software for pricing contracts.
There are a lot of problems that Prolog / Constrain programming will solve very elegantly, and much more easily than imperative languages. I think constraint based programming is seriously under used in the industry, and too many programmers are unaware or unable to write constraint based code. I have always hoped to have just a constrain based programming subsystem in a lot of languages, for those niche cases.
Full stack Java, JavaScript / TypeScript
We make a Configure-Price-Quote SaaS for complex product portfolios. For example, one customer is Tetra Pak, that sells machines that build packaging (milk, juice, etc). These machines are like a two-story building with many variations, every aspect has to be well-defined and validated before it's ordered.
In our solution products can be modeled in detail with constraints, and during a sale options are chosen and validated, often visualized parametrically, pricing is done, and a quote is prepared. All based on the well-defined model.
It's a 30-year old company that started as a research startup, grew organically, and has a stable customer base. After a recent acquisition it's aiming to grow, therefore many positions are open. I started working here just a year ago, but I can say the work environment is healthy and relaxed, lots of competent people and everyone I interacted with so far have been very nice and professional.
Senior Software Developer https://careers.tacton.com/jobs/5313129-senior-software-deve...
Technical Lead https://careers.tacton.com/jobs/5591471-development-lead
Technical Frontend Architect https://careers.tacton.com/jobs/5714212-technical-frontend-a...
Technical Enterprise Architect https://careers.tacton.com/jobs/5591490-technical-enterprise...