9 ms·

I've spent a long time trying to build "No Code" solutions. Probably 3 different products, 3 different companies. But once, I tried something different. I pu

by swalsh 7y ago

I've spent a long time trying to build "No Code" solutions. Probably 3 different products, 3 different companies. But once, I tried something different. I pushed back, instead I proposed we build a domain specific language using Ruby. I already had some trust with my boss... and he was pretty convinced it was going to fail, he had zero faith these smart (but non-technical) users could successfully use it. But he was willing to let me fail. So we tried it, and really surprisingly, they caught on very quickly, and they were producing complex content within a week. "No Code" solutions are like asking your user to communicate using pictographs. It's possible, but language allows users to communicate in better detail faster. In school I learned how to write, I'm probably not anywhere close to writing a novel. I'm a terrible writer, but I can write an email. Frankly, that get's me pretty far.

pklee 7y ago
That is really cool. How did you go about designing the language. Did you go for a full lexer and parser ? or it was more functional. Curious to understand how you built it.
- swalsh 7y ago
  Ruby's super power is it's meta programming ability. So they were really just writing Ruby. If you google, I think there's a bunch of tutorials out there for creating a DSL in Ruby... but I learned from a book called "Metaprogramming Ruby"
  - deleted 7y ago
    [deleted]
  - Stratoscope 7y ago
    Thanks for the book recommendation, I am eager to read it. I looked on Amazon but there are only used paperbacks and no Kindle edition. But I saw from the cover that it was a Pragmatic Press book, so looked for it there and they have a no-DRM ebook of the second edition - for a lot less money than the used copies on Amazon! https://pragprog.com/book/ppmetr2/metaprogramming-ruby-2 https://pragprog.com/book/ppmetr2/metaprogramming-ruby-2
  - guu 7y ago
    Very cool. Reminds me of the Ruby DSL for music performance: https://sonic-pi.net/ https://sonic-pi.net/
detaro 7y ago
Did you do anything special presentation/interface-wise? My impression is that a good part of it for many is not making them realize that they are "programming" until they've already accepted that they can do it, because otherwise they "know" that it is too difficult.
- swalsh 7y ago
  I actually wrote a plugin for sublime, which allowed them to write the script then directly upload to our service, it also had some code snippets in it so they could right click, then quickly add and modify what they needed while they were learning (this feature was not used as much though, watching them, they seemed to prefer looking at scripts that did something similar and just copy and pasting from it). But other than that, it was just sublime.
- cr0sh 7y ago
  > because otherwise they "know" that it is too difficult. This is something that frustrates me in general, and I'm sure others, too: That there seems to be among a certain population of people a mindset that declares failure before they've even tried. Or, they try, but at the first hint of failure or trouble, they declare that they can't do it, and stop. So what is different about those people who don't do this? Why do they instead take up new challenges, and when they fail, try again. When they run up against difficulty, they step back, think about their options, perhaps consult experts in the domain, and continue on? And how do we get the former group to join the latter? I know there isn't an easy answer to this, if there is one at all; I know I'm not the first to observe this issue either - it's likely something that has been observed and wondered upon for thousands of years. ...but nonetheless, it continues to be frustrating.
  - jimbokun 7y ago
    My suspicion is that it's not really that they aren't capable of programming, they just find it boring and would rather be doing something else.
    - 7y ago
vsskanth 7y ago
I second this. People can go very, very far with simple and sand boxed Domain Specific Languages that are targeted towards the core function. There are so many commercial successes for this approach: CAD, MATLAB, Simulink, LabVIEW, Dymola, Excel (?) The biggest issue with many of these tools is that they tend to be closed source, proprietary formats, onerous licensing terms, not easily extended and aren't easy to deploy into an automated production workflow. Some are addressing this with an option to export a compiled binary, but many try to up sell you complete ecosystems (PLM) to keep you locked into their proprietary formats. This tends to frustrate devs.
- deleted 7y ago
  [deleted]
- xiwenc 7y ago
  I mostly agree with you. As an independent professional, I hate complete ecosystem platforms also. We need composable systems. Not more locked down. Mendix (https://www.mendix.com https://www.mendix.com) does a lot of that well but as you pointed out it's proprietary. If we look at history, successful predecessors like C, Java and Python (sorted by difficulty) are all open standards. I think the next low/no code platform to open their specifications wins the race. Disclaimer: I've worked for Mendix.
fock 7y ago
if you just remember that all the classic unix-editors were used by secretaries/data input persons picked right from the typewriter, that's not surprising at all. What's surprising is that this insight was so fully eradicated by years of IBM/MS/Apple-marketing (except for the lone warehouses still running on IBM mainframes with terminal frontends)...
dkersten 7y ago
I’m a programmer with 15 years of professional experience and another 10 as a student and hobbyist before that. My brother is a carpenter by training who was never even the slightest bit interested in programming. Last year, he learned Pine script[1] because he wanted to customize stuff on TradingView.com. Sure, he doesn’t really understand all the details and sometimes asks me for help, but he is able to successfully get the results he wants. I think most people just need sufficient motivation and they’ll get it. I’ve always said that the reason most people don’t learn to program isn’t because they can’t, but because they don’t really have enough reason to put the time and effort in. Learning a skill takes time and tenacity. Years ago, I tried to learn guitar, but gave up after a few months because progress was too slow for me. I was impatient and not motivated enough and therefore ultimately didn’t get anywhere. Two years ago, I decided I wanted to learn sleight of hand card “magic”. There was one flourish in particular that I just couldn’t do, but I kept trying anyway. Day after day, I couldn’t do it and then one day I realised I could. The only difference between that and guitar is that I kept at it and out the effort in. Sure, some people are predisposed to certain things which is a bit of a shortcut (I definitely found programming easier to learn than card magic), but I believe that most people can learn most things, if they have sufficient motivation and put in the time and effort (I include finding a way that works for you as part if effort, just doing something repeatedly may not be enough on its own, as they say: “practice makes permanent; perfect practice makes perfect” — ie be careful of learning bad habits that may get in your way) I’m personally not against visual programming and have had some good experiences with it, but the name “no code” in my opinion completely misses the point: its still code (and programming). The text was never the hardest part, so by eliminating that, you’re not really winning much. The hard part is the logic, calculations, data manipulation and translating ambiguous requirements given by people who don’t really know what they want. Very little of my day to day is actually about the text I type into my editor, but rather the problem solving that goes on in my mind. Visual languages don’t magically make that go away, they just represent the code in a different form. Sometimes this can be really useful (visual languages make flow explicit and I personally tend to think in “boxes and lines” anyway), but often thats not the biggest roadblock. Often the roadblock isn’t the code at all. [1] https://www.tradingview.com/pine-script-docs/en/v4/index.html https://www.tradingview.com/pine-script-docs/en/v4/index.htm...
ako 7y ago
"A picture is worth a thousand words..." When doing presentations or writing, I make a lot of effort to visualize what I'm trying to communicate, as it really helps making sense of all the words. I work for a low-code, no-code vendor. We usually approach new features by first defining a DSL for a need, and than have one or more visual editors for these DSL. Every part of your application is still customizable (Java, typescript, react widgets, etc), or you can just call a microservice built in another stack.

by swalsh 7y ago

pklee 7y ago

That is really cool. How did you go about designing the language. Did you go for a full lexer and parser ? or it was more functional. Curious to understand how you built it.

swalsh 7y ago
Ruby's super power is it's meta programming ability. So they were really just writing Ruby. If you google, I think there's a bunch of tutorials out there for creating a DSL in Ruby... but I learned from a book called "Metaprogramming Ruby"
- deleted 7y ago
  [deleted]
- Stratoscope 7y ago
  Thanks for the book recommendation, I am eager to read it. I looked on Amazon but there are only used paperbacks and no Kindle edition. But I saw from the cover that it was a Pragmatic Press book, so looked for it there and they have a no-DRM ebook of the second edition - for a lot less money than the used copies on Amazon! https://pragprog.com/book/ppmetr2/metaprogramming-ruby-2 https://pragprog.com/book/ppmetr2/metaprogramming-ruby-2
- guu 7y ago
  Very cool. Reminds me of the Ruby DSL for music performance: https://sonic-pi.net/ https://sonic-pi.net/

detaro 7y ago

Did you do anything special presentation/interface-wise? My impression is that a good part of it for many is not making them realize that they are "programming" until they've already accepted that they can do it, because otherwise they "know" that it is too difficult.

swalsh 7y ago
I actually wrote a plugin for sublime, which allowed them to write the script then directly upload to our service, it also had some code snippets in it so they could right click, then quickly add and modify what they needed while they were learning (this feature was not used as much though, watching them, they seemed to prefer looking at scripts that did something similar and just copy and pasting from it). But other than that, it was just sublime.
cr0sh 7y ago
> because otherwise they "know" that it is too difficult. This is something that frustrates me in general, and I'm sure others, too: That there seems to be among a certain population of people a mindset that declares failure before they've even tried. Or, they try, but at the first hint of failure or trouble, they declare that they can't do it, and stop. So what is different about those people who don't do this? Why do they instead take up new challenges, and when they fail, try again. When they run up against difficulty, they step back, think about their options, perhaps consult experts in the domain, and continue on? And how do we get the former group to join the latter? I know there isn't an easy answer to this, if there is one at all; I know I'm not the first to observe this issue either - it's likely something that has been observed and wondered upon for thousands of years. ...but nonetheless, it continues to be frustrating.
- jimbokun 7y ago
  My suspicion is that it's not really that they aren't capable of programming, they just find it boring and would rather be doing something else.
  - 7y ago

vsskanth 7y ago

I second this. People can go very, very far with simple and sand boxed Domain Specific Languages that are targeted towards the core function. There are so many commercial successes for this approach: CAD, MATLAB, Simulink, LabVIEW, Dymola, Excel (?) The biggest issue with many of these tools is that they tend to be closed source, proprietary formats, onerous licensing terms, not easily extended and aren't easy to deploy into an automated production workflow. Some are addressing this with an option to export a compiled binary, but many try to up sell you complete ecosystems (PLM) to keep you locked into their proprietary formats. This tends to frustrate devs.

deleted 7y ago
[deleted]
xiwenc 7y ago
I mostly agree with you. As an independent professional, I hate complete ecosystem platforms also. We need composable systems. Not more locked down. Mendix (https://www.mendix.com https://www.mendix.com) does a lot of that well but as you pointed out it's proprietary. If we look at history, successful predecessors like C, Java and Python (sorted by difficulty) are all open standards. I think the next low/no code platform to open their specifications wins the race. Disclaimer: I've worked for Mendix.

fock 7y ago

if you just remember that all the classic unix-editors were used by secretaries/data input persons picked right from the typewriter, that's not surprising at all. What's surprising is that this insight was so fully eradicated by years of IBM/MS/Apple-marketing (except for the lone warehouses still running on IBM mainframes with terminal frontends)...

dkersten 7y ago

I’m a programmer with 15 years of professional experience and another 10 as a student and hobbyist before that. My brother is a carpenter by training who was never even the slightest bit interested in programming. Last year, he learned Pine script[1] because he wanted to customize stuff on TradingView.com. Sure, he doesn’t really understand all the details and sometimes asks me for help, but he is able to successfully get the results he wants. I think most people just need sufficient motivation and they’ll get it. I’ve always said that the reason most people don’t learn to program isn’t because they can’t, but because they don’t really have enough reason to put the time and effort in. Learning a skill takes time and tenacity. Years ago, I tried to learn guitar, but gave up after a few months because progress was too slow for me. I was impatient and not motivated enough and therefore ultimately didn’t get anywhere. Two years ago, I decided I wanted to learn sleight of hand card “magic”. There was one flourish in particular that I just couldn’t do, but I kept trying anyway. Day after day, I couldn’t do it and then one day I realised I could. The only difference between that and guitar is that I kept at it and out the effort in. Sure, some people are predisposed to certain things which is a bit of a shortcut (I definitely found programming easier to learn than card magic), but I believe that most people can learn most things, if they have sufficient motivation and put in the time and effort (I include finding a way that works for you as part if effort, just doing something repeatedly may not be enough on its own, as they say: “practice makes permanent; perfect practice makes perfect” — ie be careful of learning bad habits that may get in your way) I’m personally not against visual programming and have had some good experiences with it, but the name “no code” in my opinion completely misses the point: its still code (and programming). The text was never the hardest part, so by eliminating that, you’re not really winning much. The hard part is the logic, calculations, data manipulation and translating ambiguous requirements given by people who don’t really know what they want. Very little of my day to day is actually about the text I type into my editor, but rather the problem solving that goes on in my mind. Visual languages don’t magically make that go away, they just represent the code in a different form. Sometimes this can be really useful (visual languages make flow explicit and I personally tend to think in “boxes and lines” anyway), but often thats not the biggest roadblock. Often the roadblock isn’t the code at all. [1] https://www.tradingview.com/pine-script-docs/en/v4/index.html https://www.tradingview.com/pine-script-docs/en/v4/index.htm...

ako 7y ago

"A picture is worth a thousand words..." When doing presentations or writing, I make a lot of effort to visualize what I'm trying to communicate, as it really helps making sense of all the words. I work for a low-code, no-code vendor. We usually approach new features by first defining a DSL for a need, and than have one or more visual editors for these DSL. Every part of your application is still customizable (Java, typescript, react widgets, etc), or you can just call a microservice built in another stack.