Just a joke. Advent of Code is happening now and this description of your strategy DSL reminded me of what their problem statements often look like. Utterly unhelpful to you, I’m afraid.
2 Likes
I’d concur with the suggestion of Lua, if you really need a full general-purpose language rather than a DSL. In many ways I think the ‘boringness’ of Lua is an advantage — it’s easy to understand for people who might not necessarily want to spend lots of time figuring out how to extend your application. Otherwise, Dhall is also a good suggestion.
1 Like
I’d vote for Lua too, but you want something more “fun”: what about embedding @chrisdone’s Hell ? It’s a much restricted “HaskellScript” (700-LOC Haskell-like DSL for scripting). (Customize the bindings to restrict it further.)
1 Like
Don’t know much about it, but just in case it turns out to be just what you were looking for: Today I learned of the Janet language (via this blog post by Andrey Listopadov about porting Janet to Clojure, which led me to another blog post, Why Janet?, by Ian Henry).
1 Like
@maxigit just a word of caution: even if you are the only developer, a proglang/FP buff and have plenty of time and tech risk budget, beware of “Turing tarpits”. Like, maybe this is a SQL-shaped problem in disguise.
1 Like
If you want something on the Lua VM but with more of an FP flavour, you could try integrating Fennel. I wrote a blog post about this a while back.
I don’t think Dhall is what you want when you’re configuring arbitrary functions.
It might also be the sort of problem where designing a small custom DSL would let you say what you want more cleanly than with an off-the-shelf interpreter. Algebra-Driven Design might be a good tool here.
2 Likes
Fennel could be a possibility indeed.
I already have a Turing Tarpits, which I am trying to get rid of.
It’s more an css/xpath problem shape than SQL shaped.
Anyway, regardless of my actual problem I am still interested in which language be embedded easily in Haskell at runtime.
Nothing in that long message of proto-requirements sounds out of the ordinary for a decent warehouse management package. What’s more that’ll have a point-and-click interface with a layout of the physical locations so your users don’t have to remember a bunch of bin codes and lot numbers — so avoiding input errors from typos, let alone coding errors in your application. I’m wondering why you think your business is so special your company wants to pay you to have “fun”/rediscover the solutions to a series of known problems?
tldr: for nothing that you’re looking for is a DS(E)L the right answer.
You missed the important bit
Are you talking from experience ? Any pointers welcomed. All the WMS I have seen deal with “stock” and maybe location but not the actual physical way boxes are laid out in a shelf. Most big companies get thing s delivered on palette. So effectively they only have to deal with identical “cubes” (containing n boxes depending on the product), and you can fit 3 or 4 palettes on a racking shelf. They don’t have to worry about neither most WMS.
Also I’m pretty sure that any “decent warehouse package” would have some scripting capabilities.
You probably can say that from any companies having in-house software (most companies I worked for). I guess they believe that give them a competitive advantage.
Beside, it’s only a side project which I work on a few weeks a year.
Had a similar thought but from a different angle.
A question for OP @maxigit: Your example
sounds like the business wants human analysts to think through the positioning manually, which someone will then encode via the DSL.
From a different angle, this sounds like a typical industrial combinatorial optimization problem, which people solve with mixed-integer programming (MIP) or constraint approaches. Operations research experts routinely produce big economic and speed gains with these approaches.
Is any of that relevant here? Is the business open to a bigger improvement than just a handy DSL?
1 Like
Operation research would be ideal indeed, but the company is not big enough to benefit from it and we don’t spend that much time on it (there is not much to save). Also setting up the real rules would be extremely complicated. It’s just not about finding the best placement for each boxes, it also depends on external factors like the popularity of a product, moving as little boxes as possible, getting product with similar names apart from each other to avoid miss-picking and things we probably do unconsciously without being aware of it.
I’m not sure what I have done to deserve this. I was just wondering about the state of the art of scripting languages and Haskell and didn’t realize I had to justify myself.
I was genuinely hoping for a recommendation for a good WMS, but you choose to ignore this question.
Your experience is probably relevant in the T-shirt world, but unfortunately we don’t do T-shirt. It was just a name for example sake, I apologize if I mislead you. Your example of large T-Shirts next to large pants is actually a good example of how something specific to an industry/business can have an impact on the organization of the whole warehouse. What happen if you only sell T-shirt and no pants, or mugs with first name, etc …
6 Likes
@AntC2 I find your message disrespectful and absurdly arrogant. Do you really believe that you are in any position to lecture people this way, pretending that you know their business domain better and offering “right answers”?
It’s fine to say that DSLs are not always the answer to the Ultimate Question of Life, the Universe, and Everything. There is no reason to deliver this message in the way you did.
10 Likes
I think not “just”: look back at what you wrote before I chipped in. There’s talk of WMS and T-shirts[**] and all sorts of not-atall-abstract software structuring issues.
[**] I appreciated you might not actually be talking about T-shirts, but that you were faced with similarly complex product structuring, so could interpret what I wrote into your business domain. If you’d prefer, I could talk about a WMS implementation for vehicle/heavy machinery parts supply: everything from nuts/bolts/washers up to rear-axle assemblies.
a) I carefully said “proto-requirements”: not enough info to know what to recommend; b) you don’t tell your budget; c) you don’t tell your hardware platform; d) you don’t tell your geography; e) you aren’t paying me (or rather my employer) for software selection services. And I suspect the request should be coming ‘down’ from the business users/Logistics team, not ‘up’ from I.T.
@Reaper and Season’s Greetings to you too.
What I was reacting to was o.p. having seemingly already decided that a DS(E)L was the solution. And yet everything presented about the “business domain”/requirements seemed well within the capabilities of package software I have implemented.
Is there any warehouse/Logistics environment you’ve worked in where it’s reasonable to ask staff to type cryptic text commands at a prompt? Or does the solution expect o.p. (apparently a programmer) to be always present at the putaway/despatch operations to type commands? Please explain what level of service I.T. is providing to the business with such a mode of operation.
(Judging by the way my clients keep asking me back, they appreciate the way I can put technology and technologists in their place — or if you don’t like that language: put them in context of wider business issues.)
Locked at the request of OP.
1 Like