Dry.io wants to democratize software development using AI(venturebeat.com) |
Dry.io wants to democratize software development using AI(venturebeat.com) |
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."
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.
For a trivial CRUD app, the dev can just re-use one they already wrote, no need to learn this layer you've created ... and for a complex CRUD app or something more complicated than that, you're going to need to write real code anyway, so who is the customer?
Why would I as a Python, JavaScript, or Ruby webdev learn your layer, which is at risk of disappearing in a bankruptcy? What will my investment of developer hours look like in 2 years on your platform, if it's still around?
Is it basically only useful for web stuff?
The thing is, 90%+ of the time spent developing software is spent figuring out precisely what you want everything to do. Once you actually know what you want, producing the code is pretty straightforward. Rapid application development systems are always a tradeoff between development time and "control at the pixel level". I'm absolutely not saying that a better RAD tool or a better AppWizard isn't worth having, mind you! Just that the two goals are diametrically opposed.
I've had some experience around Model Driven Design and code generation tools for building web apps using technology such as the Eclipse EMF and Ecore for modelling common components.
How do you differentiate your software from that space?
Future extension you are likely considering could be voice/gesture driven development, or "natural language" programming, where one can use this combination naturally like talking to another person, describing what kind of app one needs and how it should look like.
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 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.
Contrary to popular belief, there is a lot of money in this. I sincerely wish you luck and hope you succeed.
Small things but important. You might want to fix that
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?
Maybe we should say it does to get some press! :-)
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.
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'm sure there is a market for Dry.io solution, just can't estimate how big it really is.
Best of luck with the launch, definitely interested in helping out with beta testing.
User@gmail
No offense intended, but I thought someone might appreciate knowing.
[pithy word].io, democratize (that doesn’t mean anything anymore), AI (everything is AI these days)
Without more descriptive words, it seems to mean simultaneously a whole lot and not very much.
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).
However, once you do know exactly what you want, it is still often a lot of work to actually build it in many cases. Say you wanted to build an exact clone of Slack (even v1 of Slack) It would still take weeks of effort at at the very least to build and deploy that.
I was the founder of SkyPhrase, a natural language processing startup that Yahoo acquired in 2013. Natural language was also a focus of my AI research. We have some ideas on how to apply that to this project, but they will probably have to wait at least a few months.
One way AI factors in involves finding a core set of primitives that can describe all software functionality. Programming languages and web frameworks are more granular than Dry and so they require you to write a lot more code. Dry has a higher level of abstraction than concepts like arrays, servers, divs, database tables, etc.
On the other hand, Dry is not just a template system that gives you a predefined set of application types like messenger, social network, discussion group, etc. that you can just specify. That's a higher level of abstraction and can be fairly limiting and brittle.
Dry's abstractions are in at a level that is between those two extremes; it lets your write a lot of apps without needing to be too granular.
There is research in AI called "Knowledge Representation and Reasoning" that identifies fundamental primitives that can express a wide variety of concepts and ideas. I've been a researcher in this field my whole career and was a professor in that area once. We've translated those results into software and have used them to develop a core set of primitives that let you describe the behavior of a lot of software.
I know that is all vague, but we'll start to be more precise and concrete over the next few weeks.
Part of how Dry works is that you give it a data model for your application (which can be quite complex) and we automatically generate the code for storing, retrieving, sharing, etc. that data. Normally for any cloud app that scales, this takes a fair amount of thought and expertise. We automate a lot of that without the programmer even needing to know it's happening.
I think to gain any attention in today’s environment, you’re going to have to do more “showing” and less “telling”.
Remember how Ruby On Rails got its amazing dev mindshare? I’d encourage you to hit archive.org and go back to like 2006 at rubyonrails.org. They had a compelling demo that was just a simple screen share, but it blew people’s minds. Their headlines and body copy were also excellent.
EDIT: a couple of links:
https://web.archive.org/web/20060609235209/http://www.rubyon...
https://web.archive.org/web/20060612063620/http://www.rubyon...
If that doesn't work, perhaps you can find a mirror somewhere with that link.
EDIT: Found a copy on Vimeo: https://vimeo.com/41708568
I recently change the domain from nimblapps.com to nimblehq.com which I think is much better (but didn't get Recaptcha updated.
Would love any feedback you have. It is early but some cool ideas are in there.
Thanks for the curiosity.
Isn't the point of dry.io that a business analyst can replace a developer? :)
Only within the set of predefined functionality that can be specified in the dry.io JSON config file. If you want anything outside of that you'll still need a developer. I guess it's possible dry.io will have thousands of components that covers 90% of what each and every app does eventually, but until then most people who try it will bump up against it's limitations very quickly. The hard part will be keeping them on the platform.
Many apps we won't be able to handle at first can easily be handled by our approach with more work.
For some capabilities, we will have ways of filling gaps in the platform. We have some easy-to-use and fairly flexible hooks where you can add a lot of UI customization. We've also discussed mechanisms for catching events in dry and triggering external code developers can write. But that's almost certainly not going to make v1.
I've heard that promise before, from BPMS vendors. I don't think it ever pans out, and usually results in a hobbled system that usually still require developers to actually deliver the desired functionality. I think developing software requires a specific mental skillset that can't be replaced by technology, and promises to the contrary are snake oil.
Is it a stretch to say that dry.io would enable these people to take on simple development tasks that would be currently done by programmers?
The reason someone would learn to develop on our platform is because they can build something orders of magnitude faster than they could otherwise.
At first it will be for web stuff, though we plan to add mobile app capabilities as soon as possible. Think of the space of apps that includes social networks, messengers, bug trackers, CRMs, task managers, etc. That's the kind of thing you'll be able to build at first fairly straightforwardly. Things like self-driving cars, high-frequency trading algorithms, will be beyond our scope for a very long while.
From that you construct the required model, which is then generated as code.
Getting from a model to code is pretty well covered.
Parsing the business requirements into a model whether via decision trees, or a generative adversarial network is the tricky bit.