Dry.io wants to democratize software development using AI(venturebeat.com)
venturebeat.com
Dry.io wants to democratize software development using AI
https://venturebeat.com/2019/02/26/dry-io-wants-to-democratize-software-development-using-ai/
84 comments
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.
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.
I appreciate the reply and genuinely hope you succeed, but it seems like an uphill battle and a hard sell.
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?
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?
I believe that you are not the target audience here.
Isn't the point of dry.io that a business analyst can replace a developer? :)
Isn't the point of dry.io that a business analyst can replace a developer? :)
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.
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.
It's a reasonable concern.
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.
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.
> Isn't the point of dry.io that a business analyst can replace a developer? :)
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.
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.
Every developer I know has a friend or family member who wants them to write some software for them. The friends and family think it will take a few hours, but it really takes us weeks and skills we often don't have. So the software never gets written. Dry is intended to fix that, and so therefore to help developers be more productive.
In our company, business analysts are relatively technical - they know their way around databases and understand SQL better than most developers. They do create complicated data workflows as ETL jobs, but they are not developers.
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?
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?
To do some advanced customization of how an app looks would require some javascript, but if they are happy with the UI we provide by default, then they could build some nontrivial stuff.
Business analysts are generally good at writing system requirements using BDD style syntax.
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.
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.
Thanks. We can build more-complex-than-CRUD apps with literally only dozens of lines of code in many cases. You don't need to set up any servers, know any front-end frameworks, configure/index/structure a database, etc. We don't expect anyone to believe that now, just to take a look at it when we release, and perhaps to sign up to test before that.
The reason someone would learn to develop on our platform is because they can build something orders of magnitude faster than they could otherwise.
The reason someone would learn to develop on our platform is because they can build something orders of magnitude faster than they could otherwise.
Re the risk of us disappearing: if the app someone wants really only takes a few hours or days to build then they might decide (and they can't feasibly build it in any other way) that it's worth the risk. Also, we'll make it easy for users to export their data into a machine-readable format so they can preserve their data independently of us.
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.
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.
You're points are extremely valid. They're not just competing as a platform. They're competing with the standards we work by. If seen a few platforms similar to this, and I think they try to change too much too fast.
> 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.
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.
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 agree that figuring out exactly what you want is a lot of work. Our platform only helps there in that it makes it faster to iterate through different guesses at what you might want to arrive at what you do want.
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.
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.
Hi Nick
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?
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?
Our approach is very model-driven. Three differences/innovations with respect to that work are that 1. the models we use have a few additional elements that lead to a much wider range of apps that can be created, 2. we have a way of overriding what's generated from the model by default and 3., the software behavior we generate from the model includes more elements of the conventional modern software stack (search, authentication, sharing, etc.)
Great! It's precisely how trivial stuff will be handled in the future, whether we like it or not and I am glad something like your company popped up. Could you please recommend any papers your approach is based on? Thank you!
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.
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.
We'll probably be posting a technical whitepaper and/or more technically-oriented video to the website soon.
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.
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.
"Dry.io also has no business model, yet."
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.
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.
> Cassimatis believes that Dry.io doesn’t have any competitors.
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.
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.
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.
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.
Slightly OT, but on my browser, dry.io is not on https. Big red flag for me. Chrome shows a 'Not Secure' tag for me, plus there is no favicon.
Small things but important. You might want to fix that
Small things but important. You might want to fix that
[deleted]
It's a good point. Our actual platform is all https. Our home page is just a static page. But you're right that it's bad optics for a platform intended to be privacy friendly to not be using https.
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?
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?
Yes. We have an event language where you basically can say "IF X happens do Y".
Hey that's how Watson handles AI too
The idea is that in many cases how an edge case is handle is up to the person requesting the software. So unless you build an AI that can read minds there needs to be an easy way to express what their preferences are.
Oh I remember that it ran on CBM 8096 back in 81 - I seem to recall it was called "The Last One"
Where is the AI here? This is yet another line-of-business app generator. Others include Microsoft PowerApps, Microsoft Access back in the day, etc.
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.
You actually do not have to understand the software underneath. The point is for that to be invisible to the developer.
Yes. I am wondering the same thing. We are currently working on NimbleHQ [1] which is an app that lets you build apps. And it is pretty cool. But it doesn't use AI.
Maybe we should say it does to get some press! :-)
[1] https://www.nimblehq.com/
Maybe we should say it does to get some press! :-)
[1] https://www.nimblehq.com/
Hi, I am trying to sign up but I can't get it working on Firefox and Chrome[1]. Captcha Error
https://imgur.com/xMHx0xY
Wow... that is embarrassing. Fixed.
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.
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.
I really like the concept and design. Haven't used it fully to grasp how it works yet, but I did find a few bugs at first glance.
I can send you info by email if you'd like.
Thanks man...def send over any bugs or issues you find. Still needs lots of polish. The idea though is that you can define your data model and then have a simple CRUD interface to update your app. The vision is then to start iterating on making the views more and more customizable as well as start to introduce conditional workflows to support more true app like functionality.
You can respond to the email address you get the welcome email from after you sign up.
FYI... it looks like hnchat is no longer a thing in case you want to update any way fellow HN'ers can contact you.
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.
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.
http://aima.cs.berkeley.edu/
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.
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.
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.
Artificial intelligence is a superset of, not equivalent to statistical machine learning.
Ever since expert systems fizzled out and failed to deliver on their promise in the 80s, AI has been roughly equivalent to statistical machine learning and its applications. Everything else became just logic that needs statistical inference in order to work intelligently in a complex setting.
You could label anything AI. Might as well call my if statement AI
Re AI, check out the thread where I explain how we don't use training models or conventional machine learning. We use very deterministic.
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.
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.
Sounds somewhat like Meteorkitchen from reading that story. My feeling is that it will have very little to do with AI, but let’s see.
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.
Interesting work Nick. I’d love to chat with you directly at some point, since our work overlaps in a few ways.
Best of luck with the launch, definitely interested in helping out with beta testing.
User@gmail
Best of luck with the launch, definitely interested in helping out with beta testing.
User@gmail
Thanks. I'll reach out to you offline.
Can you speak to what "AI" means in this context?
AI is an element of this in a number of ways. First, though, this is not a platform for writing AI applications. It's a platform for making it faster to write messaging, social, collaborate, productivity, etc. apps much faster than.
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.
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.
Another connection is this:
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.
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.
Yes, I understand that point, but all you explain and all I read about Dry can be done with a bunch of handcoded rules and some constraints engine or solver. The scepticism comes from everyone calling everything AI just because it attracts press + investors. I would love to (beta) test your solution whenever you are ready anyway.
But I understand your reaction. I personally love AI and started working on it during the "AI winter" when everyone told me it was career suicide. I've been to AI conference where the keynote was on ordinary A/B testing, which Sir Francis Bacon invented ~400 years ago. Web developers have been using that for almost two decades, but it was presented as a new kind of AI magic just last year at a conference.
I majored AI as well in the AI winter, but now that it is hot again I still cannot see how it helps here, but I, as I too love AI, hope you show us something!
Even if you are correct about doing it with rules and a constraint solver, rule-based systems and constraint solving systems are all AI methods. Constraint solving especially is still a very active topic of AI research and something I myself researched once.
Yeah, I guess there is the sliding scale; I really find the term AI and now ML overused. For a subset of all these topics they are active research but for practical uses there are enough methods that have not been research for decade(s). Those I am referring to. As in the broad definition our MySQL auto optimizer is AI but they are just run of the mill algos everyone knows. Anyway; I am curious!
Yes, in a sense, all computing is AI. Alan Turing was explicit in his writings that he was trying to create machine intelligence and that he saw Turing Machines as a formalization of behavior he attributed to intelligence.
Thanks for the curiosity.
Thanks for the curiosity.
You have a lot of buzzwords in that headline. I’m not planning to read TA because the buzzwords made my eyes glaze over.
No offense intended, but I thought someone might appreciate knowing.
No offense intended, but I thought someone might appreciate knowing.
So you wanted the headline to be more dry?
I'm just saying I might have read the article if the headline explained using fewer buzzwords.
[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.
[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.
This isn't a snarky response, but a sincere question: how would you have titled the article or expressed our mission? It's difficult to come up with something that's clear and captures our intent while also fitting into a single sentence. We'll take any help on that we can get.
This is less about the title/headline and more about the overall approach.
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...
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...
Here's a link to the original screencast, if you can get it to load: http://media.rubyonrails.org/video/rails_take2_with_sound.mo...
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
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
Soooo tired of companies "democratizing" things.
There are a couple points to be made on this.
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).
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).
Is the generated code readable?
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.
That is, until the VCs take over or it goes to private equity, and the new stockholders say it's much easier to monetize if you're super-opaque 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.
I'd be happy to hear more about these use cases you have in mind, either here or over email.
Where is the AI ? I thought it would be some tool which uses program synthesis.
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."