Again? Can this end with anything other than failure? It'd be nice if it could, but that seems outside the realm of possibility.
Aside from this never having worked, and being, so far as we can all tell, incompatible with the level of fine-tuning to everything from the backend to the pixel positions of the UI that people want, there are very serious problems with the business model (or absence thereof)
Some telling snippets from the article:
"Everything you build on Dry.io right now is stuck there."
“Later on, we’re going to be making on-premise stuff, so if you want to run it on a local server or something like that,” Cassimatis promises. “But for now, yeah, stuck on our platform.”
Hello. I am the founder of this company. I understand your skepticism. It's true that it is very difficult to build a fully general dev tool that's 1000x faster and lets you control everything entirely down the pixel level. We're not claiming that. We're claiming that for a broad range of software (esp., social, messaging, and collaborative software), we can make the development process orders of magnitude faster. You do lose some customization though.
There is precedent for something like this being possible and valuable. Mid-90s level web technology was very restrictive, but did make a whole class of online service much easier to build and deploy than what existed before that (CompuServe, etc.) You didn't have complete control over every aspect of display, networking, etc., but the loss in customization/control didn't prevent it from enabling a lot of very important and valuable projects.
Well at least they're not taking VC funds and are funded by the previous exit of one of the founders (though I'm guessing their previous startup wasn't profitable or had no business model aside from "get acquired ASAP").
Aiming to get acquired is cool, but at the same time, it's not really a business model.
There were definitely several broad claims made. Without seeing the platform though, within the context claimed, it’s difficult to include the entire low-code industry, especially 80%+ of the logos included in the link you mentioned, being related to an AI driven coding platform, including Salesforce.
Cool, regardless of other commenters' advice, I think you should go forward with this. I run a dev shop and I have done this with Rails and boy, does it save you a lot of time (and thus, money). But, you should ensure there isn't a learning curve for your platform. It should be in a UI that's familiar to someone who is familiar with building their apps manually. Otherwise, it defeats the purpose. As for worrying about pixel perfect designs, don't worry about those, they're the easy part. The difficult part will be the parts that contain the majority of value for a business - the backend. Frontend is as simple us throwing in a nice UI framework and mixing and matching color themes. It is good enough and works well for most clients. The ones that require pixel perfection probably aren't your target audience as it has a lot to do with the frontend than the backend.
Contrary to popular belief, there is a lot of money in this. I sincerely wish you luck and hope you succeed.
Thanks. I think that's right. There are a lot of use cases where super-precise UI control is not necessary. The early web and many blogging platforms are an example where you can get very far despite some limits on UI customization.
I'm trying to understand how this would actually work. A lot of app development for a mid-size CRUD app is around encoding business logic and handling edge cases.
Let's take a specific example. Say I'm writing a software to help manage weekly CSA (box of veggies) deliveries. Sometimes a driver will miss a delivery, and in that case, you want three options:
(1) Fully refund the customer for that week
(2) Let them another receive another delivery the next day
(3) Give them company credit
If (2) happens, the driver component needs to receive a notification for the next day delivery.
Is this in scope of dry.io? If it handles this kind of thing, how?
My point exactly, and furthermore, the whole UI looks very cumbersome. You still have to understand the software underneath in order to actually build the application itself.
In what sense is this AI? You can of course call any computer technology AI in that it is "artificial" and "intelligent" but this looks a lot like a domain specific language for describing web apps and not anything that has to do with any sort of inference.
There is a partial answer to this in another thread, but here is a response to your specific point:
It depends what you mean by inference. In statistical machine learning and deep learning, inference means predicting things using large amounts of data. Philosophers call that inductive inference.
But there is also deductive inference. Given some general knowledge (e.g., "All men are mortal") and some facts ("Socrates is a man"), you infer other facts ("Socrates is Mortal"). There is a huge amount of work in AI that has developed algorithms that do very complex and powerful versions of this kind of inference. You can use those to infer from a brief description of what you want a computer to do what the sequence of actions the computer can take to achieve that goal. You can use these kinds of methods to generate software behavior without explicitly programming the behavior in advance.
That's a link to a widely-used AI textbook. The methods that most people today associate with AI (i.e., the learning-based inference methods), are only a fraction of the overall content.
I read the article but didn't watch the video but isn't this essentially code generation/metaprogramming that we already have? In rails you don't have to write a fraction of the code that actually runs because its generated for you.
Also the AI part is very worrying. To me this sounds like a programming language where no one exactly knows what the rules are and every update to the training model could break everything. Imagine trying to debug an issue when there is no documentation or any knowledge on what is going on.
I understand the use of AI is mandatory this days for any startups, but basically this is Microsoft Access 2019 if it was online.
Access once solved the problem of creating small inhouse applications for departmental use. Since then a magnitude of online services offered the same solutions, so you don't need to create anything from scratch now.
I'm sure there is a market for Dry.io solution, just can't estimate how big it really is.
Like Access, we do aim to make development much easier, and in-house tools are an obvious first market. However, there are a lot of aspects of Dry (involving access permission, data tagging, moderation, and more) that aren't all together in any other platform. These make it easier to build social, collaborative, and messaging apps much more easily than other approaches.
From the developer's point of view, the AI should be invisible. We'd be very happy if people loved using the platform but where totally underwhelmed, indifferent, and/or unaware of the AI.
1. This is less of a "AI" issue, more of a UI/UX for specialized tools issue. Dreamweaver comes to mind especially; the moment you are trying to get something that can be flexible and accommodate different needs it is mostly about learning the tools. Often, the result is that learning the tool itself is almost harder than learning to code.
2. Any code that you generate via AI will most probably be crap. A huge part of coding is making it understandable and easy to touch later on; how can you do this without AI that has a proper understanding of the worlds (probably on the level of a AGI).
No. The point is to never have to look at, modify, or understand the underlying code. So, in this sense, it's not a typical code generation tool where if you want to tweak something you need to do a lot of work to find the right place in the code.
An interesting difference between this and "traditional compilers" is that since it's targeted to user-facing applications and the output is intentionally hands-off, there are incentives for dry to subvert developers. Imagine inserting unrequested ads or silently reselling end-user analytics for extra money. The developer might never even know, let alone be able to fix it.
Yes, any company that's serving a lot of web pages would be tempted to put ads on their pages. As the article and our website state, we are doing several things to preserve people's privacy. If we do ever serve ads, you and others can help us find a way to be super-transparent about it.
Despite the (predictable) skepticism, there are some real enterprise use-cases for something like this being served by similar "self-serve" tools. I'd be willing to take a look.
PostOnce|7 years ago
Aside from this never having worked, and being, so far as we can all tell, incompatible with the level of fine-tuning to everything from the backend to the pixel positions of the UI that people want, there are very serious problems with the business model (or absence thereof)
Some telling snippets from the article:
"Everything you build on Dry.io right now is stuck there."
“Later on, we’re going to be making on-premise stuff, so if you want to run it on a local server or something like that,” Cassimatis promises. “But for now, yeah, stuck on our platform.”
"Dry.io also has no business model, yet."
nickcassimatis|7 years ago
There is precedent for something like this being possible and valuable. Mid-90s level web technology was very restrictive, but did make a whole class of online service much easier to build and deploy than what existed before that (CompuServe, etc.) You didn't have complete control over every aspect of display, networking, etc., but the loss in customization/control didn't prevent it from enabling a lot of very important and valuable projects.
omouse|7 years ago
Well at least they're not taking VC funds and are funded by the previous exit of one of the founders (though I'm guessing their previous startup wasn't profitable or had no business model aside from "get acquired ASAP").
Aiming to get acquired is cool, but at the same time, it's not really a business model.
mbesto|7 years ago
There is a huge category of providers that do this:
https://www.gartner.com/doc/3695317/magic-quadrant-enterpris...
https://www.g2crowd.com/categories/low-code-development-plat...
I wish tech journalists would do their research.
sbr464|7 years ago
neya|7 years ago
Contrary to popular belief, there is a lot of money in this. I sincerely wish you luck and hope you succeed.
nickcassimatis|7 years ago
marcell|7 years ago
Let's take a specific example. Say I'm writing a software to help manage weekly CSA (box of veggies) deliveries. Sometimes a driver will miss a delivery, and in that case, you want three options:
(1) Fully refund the customer for that week
(2) Let them another receive another delivery the next day
(3) Give them company credit
If (2) happens, the driver component needs to receive a notification for the next day delivery.
Is this in scope of dry.io? If it handles this kind of thing, how?
nickcassimatis|7 years ago
mountainofdeath|7 years ago
gamesbrainiac|7 years ago
kough|7 years ago
nickcassimatis|7 years ago
It depends what you mean by inference. In statistical machine learning and deep learning, inference means predicting things using large amounts of data. Philosophers call that inductive inference.
But there is also deductive inference. Given some general knowledge (e.g., "All men are mortal") and some facts ("Socrates is a man"), you infer other facts ("Socrates is Mortal"). There is a huge amount of work in AI that has developed algorithms that do very complex and powerful versions of this kind of inference. You can use those to infer from a brief description of what you want a computer to do what the sequence of actions the computer can take to achieve that goal. You can use these kinds of methods to generate software behavior without explicitly programming the behavior in advance.
nickcassimatis|7 years ago
That's a link to a widely-used AI textbook. The methods that most people today associate with AI (i.e., the learning-based inference methods), are only a fraction of the overall content.
ndnxhs|7 years ago
Also the AI part is very worrying. To me this sounds like a programming language where no one exactly knows what the rules are and every update to the training model could break everything. Imagine trying to debug an issue when there is no documentation or any knowledge on what is going on.
xapata|7 years ago
nickcassimatis|7 years ago
JamesAdir|7 years ago
I'm sure there is a market for Dry.io solution, just can't estimate how big it really is.
nickcassimatis|7 years ago
tluyben2|7 years ago
nickcassimatis|7 years ago
TimTheTinker|7 years ago
No offense intended, but I thought someone might appreciate knowing.
nickcassimatis|7 years ago
htkibar|7 years ago
1. This is less of a "AI" issue, more of a UI/UX for specialized tools issue. Dreamweaver comes to mind especially; the moment you are trying to get something that can be flexible and accommodate different needs it is mostly about learning the tools. Often, the result is that learning the tool itself is almost harder than learning to code.
2. Any code that you generate via AI will most probably be crap. A huge part of coding is making it understandable and easy to touch later on; how can you do this without AI that has a proper understanding of the worlds (probably on the level of a AGI).
ohiovr|7 years ago
nickcassimatis|7 years ago
AlotOfReading|7 years ago
nickcassimatis|7 years ago
stevengraham|7 years ago
nickcassimatis|7 years ago
mlboss|7 years ago