Show HN: Alan – a low-code application platform(alan-platform.com)
alan-platform.com
Show HN: Alan – a low-code application platform
https://alan-platform.com/pages/tuts/introducing.html
177 comments
Sounds a bit like naked objects?
https://en.wikipedia.org/wiki/Naked_objects
http://downloads.nakedobjects.net/resources/Pawson%20thesis....
https://en.wikipedia.org/wiki/Naked_objects
http://downloads.nakedobjects.net/resources/Pawson%20thesis....
your tutorial page goes to http://127.0.0.1:4000/pages/tuts/getting-started.html
Sorry, go here instead: https://alan-platform.com/pages/tuts/getting-started.html
Tutorial links to http://127.0.0.1:4000 :(
Thanks for catching that... Sorry!
This is the correct link: https://alan-platform.com/pages/tuts/getting-started.html
This is the correct link: https://alan-platform.com/pages/tuts/getting-started.html
It should have a video showing the code the process and the sort of apps it builds.
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.
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.
Hey, that's good feedback thanks. We did a little video/gif of the deployment process (https://alan-platform.com/pages/tuts/getting-started.html#bu...). At some point we'll do a full walk through video, but time-wise it's expensive to do.
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.
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.
Well you’ve launched, so you should be meeting the needs of potential customers.
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.
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 disagree with your strategic view for what one should do after launch.
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.
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.
As I understand it, they already have customers, and are trying to promote this to a wide audience though.
In that sense trying to appeal to people that would potentially use your system sounds like a great idea.
In that sense trying to appeal to people that would potentially use your system sounds like a great idea.
I think a good example to follow for your project is the original Rails announcement video by DHH:
https://www.youtube.com/watch?v=Gzj723LkRJY
Maybe you can do a similar app in way less time!
> See it with your own eyes
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.
[0] https://alan-platform.com/pages/tuts/helloworld1.png
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.
[0] https://alan-platform.com/pages/tuts/helloworld1.png
There is an animated gif in the tutorial: https://alan-platform.com/pages/tuts/getting-started.html
That gif is very confusing without context and doesn't show the actual working app (except one page for a split second)
An oKay name ...
But is it sending a message, or just making small talk.
Not that Alan though ;)
Seems odd, given "It’s declarative and not Turing complete"
What? Alan Turing also created non-universal Turing machines. :-P
It's thanks to Turing that we know that a programmable machine is not Turing-complete.
Apologies for off-topic..., but can someone explain the logo to me? is it a head with legs??
I believe it is a head with a shirt collar. But at first glance, I thought it was a beer mug.
I'm disconcerted after reading this thread, seeing that some people somehow think that "low code" means "low-level code" (really?) and mistaking a collared shirt for legs. I'm going to assume it's because this post was made early in the morning and no one has had their coffee yet.
Your application is awesome!
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!
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!
I does look kinda like a beer mug, I can't unsee it! But that's probably also because on this side of the planet it's time for a pint.
It looks better with this color scheme than on the linked page: https://alan-platform.com/
It really does not look like a collared shirt. Perhaps if the collar was filled in with white...
[deleted]
How does this compare to Google App Maker? And MS Power Apps?
I guess you could compare it to the model driven Power Apps. However, Alan's modeling language is more powerful. Especially the concept of state groups that allows you to specify complex business rules in the application model itself.
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.
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.
I am not sure I get it right, but is this supposed to be a modern MS Access?
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.
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.
You could look at it like that. But because data modeling language underneath is so much more detailed and powerful, the default UI is also much more useful than what you get in Access or any other relational database. The basic target audience is similar, but Alan scales a lot better to more complicated applications.
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.
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.
Some feedback:
* "low code" is confusing
When I started reading I thought low code, meant low "level" code, something like assembly or rust. After reading a lot in the page I saw it meant not writing imperative code. I think the term Model Driven Engineering would be more appropriate: https://en.wikipedia.org/wiki/Model-driven_engineering
* How do I model business rules? How do I model a State machine?
* 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
* 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
> "low code" is confusing When I started reading I thought low code, meant low "level" code, something like assembly or rust.
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 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.
It would also be helpful to use the spelling from Wikipedia: "low-code" vs. "low code" are very different in my mind.
Why not just explain it in plain English right on the page? Expecting potential users to read a wiki article just to understand what your product is seems like unnecessary friction.
Just read it as "4GL" and pretend it's the mid-80s again. Then it will all make sense.
Low-code is a pretty standard industry term, though. Maybe not for the HN crowd but Gsuite has a low-code tool now and the likes of OutSystems have been doing it for years.
I’m more curious as to the name Alan.
I’m more curious as to the name Alan.
I understood what they meant by "low-code" before I clicked the article, but I'm just one person.
Thanks for the feedback and kudos!
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.
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.
Was the HN title fixed after your post? It's now "low-code" which I think is pretty understandable.
Yes, we updated the title to try to clarify.
Only the people who use the term "low code" seem to think its a term in widespread use.
No one else has heard of it.
No one else has heard of it.
I'd be curious to know more about this: are there specific industries or settings where it's used and valued?
That's probably the intention. You either get the term and find it self-evident (win), or you ask what that means or click so you can find out what low code means. Either way they win.
Do that relationally, win the world.
Graph databases are much more powerful and a better fit for our modeling language. However, the platform can create a live SQL database mirror if you need that kind of thing.
Can you comment a bit more on what makes graph databases such a good fit for you? As far as I can see the models seem to fit pretty much 1:1 to a relational model?
I have experienced low-code platforms, and to me your approach looks very well thought-out! Veel succes ;)
I have experienced low-code platforms, and to me your approach looks very well thought-out! Veel succes ;)
How do you take this from here to the next step?
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".
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".
Well, in this particular case passwords are always hashed. So the platform deals with that for you. Other changes to the data model need a migration, which is covered here: https://alan-platform.com/pages/tuts/migration.html
Where is the definition of the password being hashed? The tutorial defines it as text:
/* 'Users': collection { 'Password': text }*/
How does the platform know to hash that? Is it looking for magic property names?
/* 'Users': collection { 'Password': text }*/
How does the platform know to hash that? Is it looking for magic property names?
No, there is no magic :) When you set up the users at the top of the model file, you specify which property is the password.
Specifying something as password hashing as (sha256? salted sha256?) without telling it to seems like magic to me.
So to clarify, it's this password: declaration which tells the framework to hash the input?
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
The line `password : . 'Password'` points at the password property, which tells the framework to hash it. What kind of hashing isn't something you should have to specify or worry about. It's a strong salted hash and we'd like to make it even better at some point, but that's firmly in the realm of the framework implementation.
This parses to "Just trust us to get this right."
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 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.
It looks like you're using SHA256(username||password) in this example. Even if it's only an example, why use a homebrew password hashing scheme based on an unsuitable hash function and bad ad-hoc salt handling, instead of a strong standard password hash with built in salt handling? And what code/specification is required to use a secure algorithm, like bcrypt with a random salt?
People often copy from such tutorials and will then end up with insecure password storage.
People often copy from such tutorials and will then end up with insecure password storage.
As someone who's not a developer but still occasionally looks through these "build an app" tutorials, password/authentication portions always worry me. I wish I could know that best-practices were shown as far as storing/encrypting user data/passwords.
the goal is to "step in when excell starts to get in the way"
I doubt they will ever care about any of that. a "side loaded application" will likely be the answer to most of those comments.
I doubt they will ever care about any of that. a "side loaded application" will likely be the answer to most of those comments.
There is a lot the platform can do by itself, but I think you grasped it well enough. The side loaded apps are definitely the escape hatch to enable things it doesn't cover (yet).
Any thoughts on pricing model yet? I see it's free for personal use. Who do you view as your competition?
We're still feeling out the market here, to see where we can take it. It will probably stay free for personal use and then grow from there with services like hosting, etc. Pricing model for businesses is something we're looking at from case to case currently.
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.
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.
Really interesting framework. And the docs are super easy to understand; nice work!
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).
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).
Good to hear the docs are clear for someone who hasn't been "living it" for years.
I understand it's hard to put your trust into something Alan right now, so we're definitely looking at making more of it available without our direct involvement.
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.
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.
That's helpful...thanks. I had been very interested in Google's Appmaker (https://developers.google.com/appmaker/), but their model where only paid Gsuite users can access applications was a showstopper, as it made access to the general public impossible.
How do you compare yourself against other "low code" platforms in the 4GL landscape?
https://en.wikipedia.org/wiki/Fourth-generation_programming_...
https://en.wikipedia.org/wiki/Fourth-generation_programming_...
I would also like to see this comparison. Another thing is; HN is really the wrong audience for this. Technologists here will spin up a vm/container with their stack of choice. Indeed; ruby and rails, django, node, all fill the void 4GLs did decades ago.
Finding and reaching users for this type of tool is the challenge imo. Implementation is the easy part.
Finding and reaching users for this type of tool is the challenge imo. Implementation is the easy part.
We anticipated that HN wouldn't be a perfect fit, but it's a critical audience and usually open to something new. It needs to become more mature before mass adoption amongst citizen developers and exposure to the developer community is one way to make some steps in that direction.
I dunno. This is exactly the kind of thing I come here for. Even if I never use it myself, it's an idea I've thought about myself, so it's good to see someone else made it.
4GL solutions are one way to attack the problem of scaling and maintaining large applications. However, you tend to end up with a traditional code base and a relational database, without a strong core specification. Especially once you start customizing an application like that, you run into the same problems as a 3GL stack.
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.
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.
Hey Koen, congrats on you and Corno making front-page on HN!
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,
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})
}
})
Hi Chris, how are you!? It's been a while man. We've definitely dug into it a lot deeper than last time you worked on it. As you say, once you get how the models work it sticks with you :)
I've been well. Landed a software job with a company called IntegriShield doing a sort of internet rent-a-cop work, now am writing apps for a mechanical contractor called US Engineering -- turns out the construction business always runs on razor-thin margins which is kinda nice because, like, reducing cost by 1% when construction margins are only ~5% causes a 20% improvement in net profit.
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.
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.
Sounds like a good business to be in!
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 :)
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 :)
// inside of here, params has type {objectguid: string},
I don't think TypeScript has a native GUID type, but if I am wrong about that please tell me as it will make my code more type-safe.
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.)
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.)
I have to know .. any chance the name was inspired by Alan Kay? :]
Nope, different Alan ;) You'll figure it out.
All states should be defined? Then how to write an app takes two numbers and returns the sum?
Check this for an example: https://github.com/M-industries/AlanProjectTemplate/blob/mas...
Thank you for the example. I just don't want to be picky but that is church encoding. To represent a number, say 1234567, you will need million items in a list.
Ah, like that. It's a fair point, but you're interpreting the model at too low a level. You don't have to model all possible values of scalar types (number, text) because the implementation of all possible values is known. I.e. you're writing a model that will drive the behavior of the application in terms of business rules, with specifications that matter to users of the application.
(Totally speculating here) I imagine the states would be something like "have no numbers", "have one number", and "have both numbers".
And there would be some kind of transition in-to or out-of that third state that would specify the addition.
And there would be some kind of transition in-to or out-of that third state that would specify the addition.
How come the "behind the scenes code" is unavailable?
In your project, you write specifications. These are read by the runtime components (database, web client) and this specification fully defines their behavior. There is no project specific code, everything you can write in your data model is supported by the runtime components. You can look under the hood at that level, the runtimes are built in C(++) and TypeScript etc., but it's completely generic. In fact a lot of that codebase is generated.
I like that this picks up where excel drops off. But I would like to see some concrete examples. Someone here mentioned a video, that would be good, or even just a list of several specific use cases.
This is very interesting. I'm looking through the Hours [0] code. Instead of:
'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 )
I feel like there should be a link to a demo application more easily accessible. I'm interested in what type of things I could build with it, is the only way to check that out forking the tutorial repo and building it etc?
Right now it is. Getting it to run should be pretty straight forward. We should do a video demo though, so perhaps check back later this week.
I liked the developer experience right off the bat -- the way the data structures are modeled couldn't be more elegant.
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.
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.
Both approaches have their place. If the problem you're solving is best served by an "old fashioned algorithm" you can hook up a side application to your core system. The interface you define between the side app and core ensures your data never gets into a weird state because your algorithm didn't cover a case. For instance, for some projects we hook up to the Preactor planning system specifically to use their algorithms.
On this page:
https://alan-platform.com/pages/tuts/bottom-up.html
The ASCII art isn't rendering correctly. (In Chrome on a tablet.)
The ASCII art isn't rendering correctly. (In Chrome on a tablet.)
Damn, I was so proud of that. You should bookmark it so you can enjoy it on a big screen later ;)
Also broken on my 24" monitor (Chrome on Windows)
Same for me, widescreen FF62 on Windows 10 FWIW
Ah, weirdly, removing 'Source Code Pro' from the font-family then renders it correctly..
Which is odd, because that's a mono-space font, I'm sure.
Which is odd, because that's a mono-space font, I'm sure.
Correct rendering on Firefox, Chromium and Netsurf on Debian testing, wrong rendering on Firefox Mobile and the Browser app on Android.
Most probably a font issue.
Most probably a font issue.
Any thoughts of totally revamping the syntax of this declarative language? Perhaps borrow some inspiration from Ruby or some other humane english-like programming language?
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.
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.
As much as I like the idea. There seems to be a fair number of requirements. I don't particularly feel like installing an 'alan' server, or an 'alan' connector just to test out my application.
Is there any reason why 'alan run' couldn't do these things for me automatically and run it on my local host?
Is there any reason why 'alan run' couldn't do these things for me automatically and run it on my local host?
Well it could. We find in practice that it's easier to just have a server running "somewhere" (locally if you have the resources) and push applications to it. But if the feedback shows that the first-run experience needs to improve that's definitely an area we would be looking at.
My experience has been that it's valuable to have an easy way to spin up a local server/runtime stack, for a wide variety of reasons.
I agree. I think people would be far more likely to try it out if you could kick off a dev server from the CLI without having to fire up any extra processes.
[deleted]
I've long thought that this is the way applications should be built. 90% of what we do as app developers could be automated away. This looks really promising.
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.
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.
Thanks for the feedback, this is exactly what we're looking for here. Perhaps some of this is "how to launch a platform 101", but we can't guess all the concerns everyone may have. Also, we're not necessarily looking to really kick start adoption for a wide audience right now. The platform lacks maturity on a number of levels to properly support that.
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.
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.
"Pretty apps isn't what you'd use Alan for"
Wouldn't a visual model bulder speed up the creation of all those declarative data models?
Wouldn't a visual model bulder speed up the creation of all those declarative data models?
It definitely could. However, written language is really powerful. We're still developing new features for the modeling language and keeping the cost of each iteration down is super important for us. A visual editor is something that would definitely help empower our target audience, but right now it would get in the way. I would love building something like that some time in the future though.
I second the GP's sentiment regarding code availability. Most of your repositories are MIT-licensed, yet you claim that the platform will be non-free (CC-BY-NC). Could you please clarify whether the server source code is or will be made available under this license?
IMHO could show a UI demo written in a different language as a "side-app", as long as the core data model is in Alan; that would make it easier to see the power of Alan.
> 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).
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.
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.
Fair points. Honestly I think our default UI looks pretty rad and it’s super important to us.
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 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.
Even if you don't think that users will pick your product because great UI is the top priority, it's likely that avoiding bad UI is still high on the priority list. Passing that hurdle means showing the UI.
I'm getting the feeling that this thing is for developing form-and-table based UI, which is pretty damned utilitarian and arguably hit its design peak in the 90s, with only slight spins from then onward.
> 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.
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.
Only by the niche that is aware they are writing throw away applications.
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.
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.
> 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
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.
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.
If prettiness isn’t a key selling point, doesn’t mean it’s not gorgeous. Sorry if it came across like it’s not a priority for us. But it’s not what sets it apart: all our competitors also have pretty apps, they don’t have our language.
As dev AND ux designer I ask you to, please, not to forget that most of decision makers have been in a situation where they had to throw away a medium to big system whose UX was blatantly old and poorly executed because it was on top of something similar to Alan. (This is just 4GL again)
As a UX designer / dev I ensure you those concerns are front and center for us ;) The modeling language basically ensures applications are easy to understand, and we have lots of solutions to make them easy to use as well.
If they are "front and center" they should be covered by your front page, probably also centered :P
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.
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.
> 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.
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 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.
Even if you don’t want wide adoption quickly, you’re obviously looking for feedback from a select group and that should entail thoughtful guidance and enough information to not roadblock the feedback process. This point is simply a rationalization, recognize that and you’ll be better off.
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.
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.
> We understand people want to see the UI, but it's not the key selling point.
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!
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!
I agree that 90% of app should be written this way.
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.
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.
Kind of amusing that it is named after Alan Turing when one of its major features is not being Turing complete by default.
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
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
How are you going to differentiate against Mendix or ServiceNow?
At the moment their offering seems to be much more mature. Niche strategy? Price? Open Source community? Grow faster (needs more money)?
At the moment their offering seems to be much more mature. Niche strategy? Price? Open Source community? Grow faster (needs more money)?
They have a head start in getting to the market. We need more time to reach their level of maturity, but we believe we have the core concept and technology to surpass them quite a bit. For the really large projects our focus on the core specification already makes a difference.
Somebody should implement this with Ruby DSL over RoR.
The oldest project I know of that tried to do something similar was Naked Objects, which later became Apache Isis (the Java version at least).
What's the difference between Alan Platform and Apache Isis?
What's the difference between Alan Platform and Apache Isis?
We definitely have had experience with Naked Objects before this. I can tell you the main difference between Alan and Naked Objects is the modeling language under the hood. Which in Alan's case is a specific for its use, whereas in Naked Objects, it is something like Java or C#.
As an Alan, I'm not sure how I feel about this.
How does this compare to http://jasonette.com (besides the obvious platform differences)?
I don’t know jasonette in detail, but you should think of Alan primarily as a way of building and iterating on apps with lots of guarantees about data quality and matching specs, not necessarily a way to build an app quickly.
How does it compare to the current low-code/no-code platforms such as Caspio (https://caspio.com), Zoho Creator(https://zoho.com/creator, or ZenBase (https://getzenbase.com)?
Not exactly a fair comparison because zenbase is NO code, one more step further. With zoho, one must also learn a rather strange proprietary programming language called Deluge.
How do you deal with performance issues with this kind of abstraction?
Because we continuously reuse use a fairly limited number of patterns we get to optimize the hell out of them. At a generic level, not specific implementations, but you can still make them fast.
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.
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.
But you are releasing the server binaries for people to run on arbitrary hardware. Surely different CPUs and machine profiles move the performance thresholds on various dataflow implementations?
It's interesting to me that the positive HN response seems to show that programmers do (publicly) like CRUD generators and RAD (rapid application development) but only if there's no front-end.
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.
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.
Actually, in the early days we thought about whether to go text-based or not, for instance going for a boxes-and-lines type of modeling environment.
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.
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.
Most model editors for CRUD aren't boxes and lines, since as you say moving around and connecting boxes isn't generally useful. So I'm not sure why you were starting with that UI.
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.
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.
The boxes-and-lines is a very common way of visualizing tables and relations or types and subtypes and/or components. Also in most other so called low-code platforms. That is why it was under consideration: familiarity. I agree it is not very useful though.
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.
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.
Tutorial has some issues. “from_scratch.migration” should be “from_zero.migration”, and visiting server_ip:7584 gives an invalid address error. This is after downloading the virtual box image, installing Alan connect, doing the build steps, importing the built image and starting it.
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.
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.
Also can’t find a valid username/password for Hours. There is what looks like a username (hello world) and password in the source but they don’t let me log in.
Thanks for catching that. Did I mention we're still moving fast and breaking things? ... Sorry. The tutorial text should be fixed, will be looking into the Alan Connect app.
No worries! Nothing is ever perfect on launch day.
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.
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.
Thanks for understanding.
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.
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.
It would be nice to have a simple example application code and demo.
Something like TodoMVC seems like a reasonable place to start.
Something like TodoMVC seems like a reasonable place to start.
Out tutorial runs you through setting up something small, and example code lives on GitHub: https://github.com/M-industries/AlanProjectTemplate
"Alan" is presumably named after Alan Turing yet this not Turing-complete...
That is an odd naming scheme...
Whats next? a Lisp called "NoBrackets"?
That is an odd naming scheme...
Whats next? a Lisp called "NoBrackets"?
It is Turing-incomplete. Turing gave us the concept of computational completeness, which requires the complementary incompleteness in the same breath.
How would you handle workflow? A simple example: email manager when a timesheet has been supported for approval.
We'd set up a derived collection of "timesheets that need approval" and export that to an emailer system. Every time a new entry shows up in that collection the emailer will send out an email to the respective manager (whose email address would probably also be part of the data exposed to the emailer system).
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.
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.
Back in the peak years of ERP (90s), as a fresh graduate i started my career in a company called BaaN. It was one of the big two SAP (Germany) & BaaN (Netherlands). To give a sense of its capability, it is the product that Boeing chose as its ERP, Boeing being the most complex challenge for any ERP!
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.
http://www.baanboard.com/node/46
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.
http://www.baanboard.com/node/46
Great idea. We were looking for something close to Alan for converting an internal app
It looks cool, but I have no idea how to use it. You guys need to give a proper tutorial page, where you show how to from 0 to working app.
> 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