Show HN: Alan – a low-code application platform
alan-platform.com
alan-platform.com
That having been said, I'd like to echo some of the other comments here. You need better docs.
As an app developer, I want to see some things right away:
1. What's the server written in? Can I see the code? It isn't clear which of your Github repos contain the server. If your server is proprietary or secret, make that clear.
2. I'm not going to install VirtualBox. Just give me a binary that I can install so I can see what's going on.
3. I want to see what a finished app looks like. Either do a video, or better yet, put up a demo site. Don't make me install the Hours app just to see it.
4. What is the Alan Connect app? I want to see it before I install it.
5. Give me a way to escape the system. I get that I don't need to write code, but for some things, I really do. In what language do I write custom functions? How do I customize the UI?
I understand that I could slog through the docs to find the answers for all these things, but your adoption rate will go way up if you make it easier. When I evaluate new software, if I can't find the answers to the big questions in 20 or 30 minutes, I move on.
We'll continue to work on our documentation and clarify some of the things you mention here. A grab bag of quick responses:
The server is in-house, written in C and C++ and (at this moment) closed source.
If you're on Linux or MacOS you can simply run the server from the command line: https://alan-platform.com/pages/tuts/reference.html#starting...
We don't support custom functions, but we do support custom applications that run alongside the stack. They can be written in anything, and we have tools to quickly develop such systems in JS, TypeScript and C++. They're not part of what we're making available to community users right now, so documentation is still a bit limited.
We understand people want to see the UI, but it's not the key selling point. Pretty apps isn't what you'd use Alan for (although you could). We try to focus on the modeling language, as it's hopefully unique and cool enough to draw the right audience in.
In my humble opinion, I would suggest rethinking this.
I imagine you don't intend to sound that way, but a response like this might suggest to people that you don't value user experience or good design, which would rule a lot of otherwise-interested people right out. For any serious project, how it looks and how it feels is every bit as important as how it functions. (Even for B2B or internal-only needs, this regularly remains true).
If I can't build a gorgeous, industry-leading well designed app in Alan, then there needs to be clear information about how I would do that outside of Alan while using your platform. Otherwise, Alan is just for disposable apps / throw-away apps / Excel-replacement apps, and for any serious work, I'm eventually going to have to rewrite the whole app in something else anyway so I might as well start there first.
There's no reason to be so elitist. Disposable applications can become important in business, they're often the duct tape that holds a small or medium sized company together. If they can be written more quickly and with more functionality than in MS Office apps, there's a very legitimate and actually very large use case for Alan.
No one "asked" for Excel applications, Excel was there, and applications started getting written in it.
Alan has to be installed on-purpose, it can't be used accidentally like Excel was. Part of the (global) utility function is how something looks.
I think we need to do a Show HN at a later date to showcase it. There is so much to say about the platform, we wanted to focus it on the modeling language right now. I totally understand people want to know more about the UI though.
I don't understand this. Whether you consider the UI to be a key selling point or not, it is still an indispensable part of the product. For me, the fact that I can't even see a screenshot of it is extremely off putting.
Imagine if Tesla didn't have any photos of the car in their marketing materials, just diagrams of the electric engine. "The key selling point is the electric engine, not the body." So what if it's not the key selling point? Even if a customer's priority is the engine, they are going to want to know about other aspects.
If the UI is a no-go for a potential user's use case, then what doesn't matter if the you totally ace the modeling language? Of course, lead with the modeling language if that is your unique selling point, but don't make people literally install software to see the UI.
I'm extremely confused as to what on earth the product is then.
If the UI is not important here, who are the key users you're expecting?
From your site:
> Alan is a low code platform, enabling efficient and low cost development of tailor-made software applications.
So I can quickly make a software application, ok.
And it should have great UX baked in:
> Furthermore, applications would be easier to use, because they would be generated with excellent UX baked in, and implementations cannot introduce magical or unintended behavior. People would also never need training for new applications: they would already know how to use them.
And it has generated and custom UI and dashboards:
> It includes both fully generated and custom built graphical user interfaces and dashboards, running on desktops, touch terminals, hand-held devices etc.
And you have a headline:
> See it with your own eyes
You want me to see it with my own eyes, and give me a tutorial and the code that would allow me to do so. But you don't want me to see it before then?
So there's a UI that it makes. This UI is the final actual output of the code I am writing. And it's not the key selling point?
I'm not trying to be an arse but I want to really convey just how strongly I feel that your page should show me some actual examples. Screenshots are fine, but demos would be the main thing I'd aim for. You have an animation in your tutorial, which is good, but then it seems that it only shows launching an app then stops!
And yet,
> This makes it ideal for administrative tools and data gathering > Solutions built with Alan include everything from small accounting systems you can build in an afternoon, to large ERP solutions.
I really pity the users of those systems then.
Anyway I'm intrigued, but being it closed source means there's a huge "NO" for me written on top of it. Even if it's source code included (as in "we give code snapshots to customers") this means it is not the kind of project I would bet on.
Same with not wanting to show the UI because it’s not the main selling point, I’ll assume it’s a rationalization or diversion, and will guess the real reason is it’s not fully baked yet or not impressive. Other wise it soesnt hurt to let it be seen.
If this is true, remember there’s nothing wrong with things being at an early state of maturity at a startup. Just be up front and say we want to show xyz as soon as practical. People understand that.
Wouldn't a visual model bulder speed up the creation of all those declarative data models?
I think the problem is that clients think of software development as something analogous to design or architecture. If we took a more utilitarian approach to software and a more expert-driven design process, we could bring costs down and reliability would go way up.
This is absolutely the way to go for the future. Computers need to be quickly and easily programmable in a standardized way that anyone can learn in highschool and still use daily for at least a few decades into their professional lives.
* How do I model business rules? How do I model a State machine?
I want to specify that once an order has been created I want to send it to the procurement department.
* You mention that you have an ERP system based on this platform. Can we look at that code? Can we have some testimonials?
Kudos: * It's good that you are doing a declarative approach to business software... this is still most of the software we use and I don't think it's a solved problem.
* On using a Graph database I think this is better to model complex domains. However which graph database are you using? Neo4j, Dgraph, OrientDB or is an inhouse graph database?
* On the name
Alan is definitely related to model driven engineering. It's a different take on what a model can specify, and models drive everything we do.
https://www.m-industries.com has some testimonials. We can't share those particular data models, but if you're really interested get on the forum and we can dig into some of those areas.
External systems can be interfaced with using our bridge application that can work with relational databases. We have tooling to rapidly build custom connectors using our interface specification language. One area that Alan shows it's still early days is that we don't have a shelf full of ready made connectors.
Our stack is all home grown. We run on a tiny custom built Linux distro. The graph database is also in house. There wasn't anything out there that fit our needs (like being 100% push/subscription based). Luckily Alan also helps keep our line count pretty low throughout the stack.
I expected that as well from the title but at the very start they link the meaning of the term so that those of us that don’t know what it means can quickly find out on Wikipedia.
I think it’s best to do like they are doing and link the Wikipedia article.
I’m more curious as to the name Alan.
No one else has heard of it.
I'd love to. You need to show it on this page.
Even if a screenshot (or screen capture, or some code) is pretty useless, it helps give the right context, and tells me this is actually a thing, and not just a hope.
This [0] should be front and center.
I can definitely confirm for others reading this that it indeed has been something like 10 years in the making; I was working with a prototype of it 8-9 years ago and found those data models so nice that I actually reimplemented the core idea in a repository on GitHub, though it didn't really go anywhere except for my own web site. I have also been able to reimplement it in TypeScript more recently, so that there is a non-Turing-complete subset of algebraic data types (though maybe I'll be able to add a fixpoint operator, who knows) as runtime objects with highly specific TypeScript types that are inferred from the functions you use to construct them. So then a parametric TypeScript construct,
ValueOfType<typeof mySchema>
myHTTPRouter.get('/objects/by-id/:objectguid', {
params: {
objectguid: {
type: 'guid'
}
},
async handler(params) {
// inside of here, params has type {objectguid: string},
// and VSCode knows this, because params is ValueOfType<schema> where
// the schema is specified in the `params` key above.
return response.json({success: true})
}
})
// inside of here, params has type {objectguid: string},
The `string` type here comes from a mapping that the router is using. That is, the router ultimately type-evaluates a `ValueOfType<{type: 'guid'}>` to `string`. But because it's a runtime object, the router can also, at runtime, validate that URL param, "did they actually give me a UUID?" -- and sanitize it, e.g. "convert all UUIDs to lowercase."
(In fact the benefit of having this TypeScript type at runtime is even bigger than that. With Express.js, the router can rewrite the route param so that the route doesn't even match if you don't provide a UUID, which matters because there is often a lot of accidental ambiguity in HTTP APIs -- but here you can embed the UUID regex into Express paths. The router can then also do some other trickery like confirm at initial load time that all params in URLs match params in this `params` dict, and it can convert all of its routes to OpenAPI/Swagger docs so that you can define another route which just gives you your OpenAPI JSON. Literally in what I have written the above would be a type error because the `Router` class would complain that `params` has the wrong type because the `objectguid` descriptor needs a key called `doc` which is a string for parameter documentation for OpenAPI.)
This is great work, and I think you're burying one lede, which is that it looks like you've embedded a declarative permissions model in this thing, and I built one of those and the time saved can be huge when authorization is handled at the model level rather than everywhere in the business logic.
The permission model actually only landed a few weeks ago, so we haven't been able to fully appreciate what we did ourselves. You're right though, it's probably a pretty huge deal :)
This effort for very high level code for building applications reminds me of Eve[1] as a non-traditional programming language (now not actively developed AFAIK, so more suitable for study than actual use). Both languages are designed to be accessible to people who aren't developers and making it simpler for people solving problems.
Love how Alan is trying to close the gap between requirements and actual code. At least for me, one of the things that has bugged me about writing in a language such as Java is tracing code to requirements. For Java the first thing to think of to solve this is discipline and complete documentation. I mean there are things like using a traceability matrix[2], but are there better ways to find or represent the relationship between requirements and code. There have been things commonly proposed to programmers such as Test Driven Design, but they are for making sure that the requirements are met by at least some of the code, not for tracing code back to requirements. Are there better ways to manually checking? Perhaps formal methods for tying requirements to every bit of code in a project, or anything else. Maybe languages and platforms like Alan are the way forward on this issue for a lot of things. Counterpoint, I don't know of any real effort from me or anyone I have worked near to trace code to requirements, the effort has been only to make sure requirements are satisfied, it doesn't seem to have caused any issues, so maybe it is only worth it for safety critical code.
[1] Eve: http://witheve.com/ [2] Traceability matrix: https://en.wikipedia.org/wiki/Traceability_matrix
https://en.wikipedia.org/wiki/Fourth-generation_programming_...
Alan plays a longer game, with a drastically different approach to specification and development of applications of any level of complexity. Models drive everything and you can't look "under the hood" to look at or modify the implementation. Even at the level of the platform itself, models and code generation drive down the amount of 3GL code we have to deal with. WYSIWYG editors and drag-and-drop UI builders aren't a starting point, it's something we might grow towards supporting in the future.
Finding and reaching users for this type of tool is the challenge imo. Implementation is the easy part.
> Instead of the traditional relational database + 3GL or 4GL language, the core of Alan is a data modelling language that automatically generates full stack applications.
If you'd like to know more, we'll be monitoring this HN post and we have a forum: https://forum.alan-platform.com
https://en.wikipedia.org/wiki/Naked_objects
http://downloads.nakedobjects.net/resources/Pawson%20thesis....
If it is, I think it is a very welcoming innovation. I believe there are a lot of use cases in business that are currently under-engineered into Excel or over-engineered into complete web apps, SAP or salesforce applications.
BTW, it is a mystery to me why MS Access itself, that is still around, lost this post.
As you say, we see Excel being stretched to doing things it cannot do, and on the other hand custom apps being built for things that don't need to be so specific. There is a place for low code the way Outsystems does it for instance, but we believe a lot of businesses would be better served by something like we're offering here.
Let's say I want to develop a multi user todo and I've followed the examples and now have some Users who log in entering a password.
Someone points out that I shouldn't be storing passwords in plain text so I want to store them hashed.
Despite there being hints in the documentation that this is possible (migrations shows the password hashed), it's not clear how to carry out this kind of change.
A walkthrough of making a change would help convey the use case much better than just templates of "this incantation produces this output".
People often copy from such tutorials and will then end up with insecure password storage.
/* 'Users': collection { 'Password': text }*/
How does the platform know to hash that? Is it looking for magic property names?
So to clarify, it's this password: declaration which tells the framework to hash the input?
users
dynamic : . 'Users'
password : . 'Password'
interfaces
root {
}
numerical-types
I think you may have some issues persuading customers that's a wholly valid approach, especially when you're dealing with security and data integrity, GDPR, and so on.
I doubt they will ever care about any of that. a "side loaded application" will likely be the answer to most of those comments.
'Week Day': stategroup (
'Monday' -> { }
'Tuesday' -> { }
'Wednesday' -> { }
'Thursday' -> { }
'Friday' -> { }
'Saturday' -> { }
'Sunday' -> { }
)
'Week Day': stategroup ('Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday')
'Week Day': stategroup %w(Monday Tuesday Wednesday Thursday Friday Saturday Sunday)
'Active': stategroup @default: 'Yes' %w(Yes No)
'Subsidized': stategroup @default: 'Yes' %w(Yes No)
'Active': stategroup @default: 'Yes' Boolean
'Subsidized': stategroup @default: 'Yes' Boolean
can-create: user +'Roles'?'Manager'|'Yes'
|| user +'Roles'?'Project Manager'|'Yes'
can-update: user +'Roles'?'Manager'|'Yes'
|| user +'Roles'?'Project Manager'|'Yes'
|| equal ( user , $ >'Project Group'>'Owner'>key )
can-create: user +'Roles'?'Manager'|'Yes'
|| user +'Roles'?'Project Manager'|'Yes'
can-update: &can-create || equal ( user , $ >'Project Group'>'Owner'>key )
Edit: Looks like the Alan connect app needs to be restarted after adding the image. Clicking “advanced” nothing was running, it’s fixed after reloading.
It’s a nice app you have here. My gut instinct is that you will need to allow under the hood customisation if you want it to really catch on. Your potential customers will be afraid of getting 90% of the way to their goal and realising that the last 10% is impossible.
You’re not alone with that gut instinct. We haven’t run into that problem though. Also, that last 10% can probably be achieved using a custom side app, or a custom front end. We didnt cover that in detail in the introduction, but the options are there. Also, current traditional approaches aren’t guaranteed to get you near 100% either. They may hold the promise of getting there, but we’re usually dealing with clients who understand that most projects don’t make good on that promise.
./.alan/dataenv/system-types/datastore/scripts/generate_migration.sh migrations/from_zero systems/server/model.lib.link --bootstrapIs there any reason why 'alan run' couldn't do these things for me automatically and run it on my local host?
At the moment their offering seems to be much more mature. Niche strategy? Price? Open Source community? Grow faster (needs more money)?
I don't buy that it's actually better without a UI or that you can't make a UI for configuring complex models (it's hard but has been done many times before). But like I said, programmers seem to accept it more readily without the UI so maybe that's the trick to programmer popularity for these types of systems.
We concluded that for serious modeling, 80% or more of what one does is giving names to concepts, leading to the usage of a lot of text any way. And that boxes-and-lines introduces a lot of 'clutter' which is probably meaningful, but not in a strict enough way to do anything useful with it: x/y coordinates of boxes and lines.
That's next to there being a lot of tooling available when going text based (editors, versioning, etc), which is more of an added bonus in the short run.
In the end, we will probably evolve in the direction of using a projectional editor, making it possible to have some boxes-and-lines modeling environment as well.
To me, projectional editing is the most sensible type of programming. Unfortunately projectional editors have not had as warm a reception on HN, because programming is narrowly defined by complex text editing. Anything with a UI and programmers are afraid they will be accused of being users. It's dumb, and most won't realize it or admit it, but that's what it comes down to.
Projectional editors can of course show the model as text and in other formats as well, like boxes-and-lines. You wouldn't be able to permanently place them in any specific spot then, so moving them around would at most be supported during a viewing session.
What's the point in forcing non-coders to write "-> {}" multiple times for no reason?
As for Ruby, you can be like Matz and strive for happiness by minimizing syntax and maximizing readability.
The ASCII art isn't rendering correctly. (In Chrome on a tablet.)
Most probably a font issue.
Which is odd, because that's a mono-space font, I'm sure.
BaaN were pioneers in this kind of 4GL thinking and made some revolutionary stuff!
The product since then is sadly now a living a zombie life with its existing customer base. The link below gives a sense of what they provided.
However, this put a crimp in my enthusiasm:
"[Alan] defines all possible states of the data, and in effect all possible states of your application"
We recently finished refactoring a complex algorithm that got away from us because we coded it as a state machine rather than a plain vanilla algorithm using good old sequence + iteration + selection. The state machine version may have been easier to write, but the old fashioned algorithm was so much easier to reason about and maintain.
What's the difference between Alan Platform and Apache Isis?
There are some other mitigating factors, like:
- the datastore is fully in memory
- you can spin up multiple datastores to share the load
You also don't tend to accidentally run into a performance issue. The constructions that cost more (e.g. nested derived collections) or are risky (kicking of derivations at a high interval) are known beforehand. You tend to know already if you're going to use a lot of memory or expect high CPU load.
I have experienced low-code platforms, and to me your approach looks very well thought-out! Veel succes ;)
Something like TodoMVC seems like a reasonable place to start.
Competitors include Mendix, Outsystems etc., when it comes to low-code and serving citizen developers. Excel as well. On the other hand there are still a lot of custom implementors out there that try to solve similar problems for businesses.
I'll be interested to see where it goes with pricing. It's hard to start building on a platform if you don't know if it's going to become too expensive in the future.
Paid hosting seems like it would work really well for a system like this (though I'd encourage some type of open-core model as well, so people have some escape hatch if the company goes under).
All I can say right now is that you should just give it a go, I bet it will change the way you look at code. If you do eventually want to build something critical on Alan, get in touch with us and we'll get the contracts set up to support that properly.
I’m not doing the tutorial.
I’m sufficiently interested to give it a 30 second video. If that looks interesting I might look at more involved videos about some aspect.
The flow is pretty bare bones though, so if you're used to a text editor and command line tools it'll be pretty familiar.
In your shoes I’d turn around and make a 1 minute video and upload it to YouTube within 20 minutes, showing what your system is and what these data structures look like.
If you have an Apple Mac, the screen recording is built right into QuickTime, just plug your telephone headset into the machine to record some narrative as you go.
Seriously, why launch without showing people what it is? 10 years coding, not willing to spend 5 minutes to record it and show us?
I’m not interested in reading about the deployment process. Really not.
Sell me on what you made.
I think the focus should be meeting the needs of actual customers. And an intro video for people who are still deciding if they will give a chance is not one of those needs by definition.
Right after launch, you want to iterate the product for your actual users. After-launch is not growth phase, is product/market fit phase. Some friction that filters out customers that are not of the early adopter profile might even be desirable.
The only exception is if you do not have enough customers to get feedback from, then you work on this sort of thing.
An important, if subtle, point is that I am not against sales in this early stage, I am all for it. I am against investment in inbound growth-only tactics. Founders doing early sales can both overcome any deficiency in a landing page, learn about what is the best message, and improve their product along the way.
In that sense trying to appeal to people that would potentially use your system sounds like a great idea.
So, in essence, you hook up a separate system to a part of the data (we have a system ready made for this particular use case), and the datastore will push all changes in that data to this system.
And there would be some kind of transition in-to or out-of that third state that would specify the addition.
However, the logo to me did look like a blood bag with some yellow liquid in it and two tubes sticking out at the bottom. (When shown on white background, you cannot see hair on the guy's head - https://alan-platform.com/pages/tuts/introducing.html ) Anyway, the program looks very intuitive in its purpose and goal!
Any relation to the defunct Microsoft Oslo/M-Language model-driven development platform?
That is an odd naming scheme...
Whats next? a Lisp called "NoBrackets"?
This is the correct link: https://alan-platform.com/pages/tuts/getting-started.html
It's the process of laying down the rules for the data in your application that drives development in Alan. Unlike Google App Builder, you don't start from a drag and drop UI builder. Although a drag-and-drop UI builder is something we might want to add at some point. For most applications though, the generated UI is plenty powerful, because what it needs to support is perfectly specified in the datamodel.