4 ms·

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 w

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.” "Dry.io also has no business model, yet."

nickcassimatis 8y ago
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.
- PostOnce 8y ago
  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?
  - nickcassimatis 8y ago
    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.
  - nickcassimatis 8y ago
    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.
  - jmickey 8y ago
    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? :)
    - nickcassimatis 8y ago
      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.
      - jmickey 8y ago
- taneq 8y ago
  > 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.
  - nickcassimatis 8y ago
    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.
- dwd 8y ago
  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?
  - nickcassimatis 8y ago
    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.)
- bitL 8y ago
  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.
  - nickcassimatis 8y ago
    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.
omouse 8y ago
"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.

nickcassimatis 8y ago

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.

PostOnce 8y ago
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?
- nickcassimatis 8y ago
  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.
- nickcassimatis 8y ago
  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.
- jmickey 8y ago
  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? :)
  - nickcassimatis 8y ago
    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.
    - jmickey 8y ago
taneq 8y ago
> 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.
- nickcassimatis 8y ago
  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.
dwd 8y ago
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?
- nickcassimatis 8y ago
  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.)
bitL 8y ago
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.
- nickcassimatis 8y ago
  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.

omouse 8y ago

"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.