41–50 of 98 posts
Examples: ToolJet: https://github.com/ToolJet/ToolJet Obsei: https://github.com/obsei/obsei n8n: https://github.com/n8n-io/n8n
What if i tell you, code is the "no code" tool itself. Why ? You of course could run any code with assembly or machine language, but now we have high level programming languages, it's because we want "low-code", or "low machine-code". The point is we want to map business problems/solutions into machine, code is just a "no code" tool which allows u to do that.
Yep. The problem is not that that programming languages are create an undemocratic force field around programming, it's that only very few people can efficiently translate any sort of requirements into any sort of machine-comprehensible instructions, doesn't matter if it's code, excel formulas, multitude of ERP checkboxes or something else. The high demand and pay of the last few decades brought a lot of people into…
The issue is how the education system and teachers don't know the principles behind programming. They teach Algebra but they can't apply that knowledge to programming.
> Another way of looking at low-code is to take an even bigger step back, and look at the history of programming from the start. Python is low-code relative to C++; C and FORTRAN are low-code relative to assembler; assembler is low-code relative to machine language and toggling switches to insert binary instructions directly into the computer’s memory. That is the most stupid thing I've read in a while.
> That is the most stupid thing I've read in a while. Arrogance. It takes 10 lines of Python to compute a multiplicative inverse mod p, using arbitrary precision integers. [1] Try doing the same thing with nothing but x86 assembly and Volume 2 of Knuth's AOCP. It's a useful, humbling exercise. [1] https://karpathy.github.io/2021/06/21/blockchain/
I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards. Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code…
Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me.
One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements.
It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once.
Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny.
I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.
Let me tell you: no/low-code solutions can be just as hard as if not harder than actual code in some cases. One of the more difficult engineering solutions I have had to implement in my career was with a tool called Tasktop, which synchronizes different requirements analysis tools like Jira, Jama, GitHub Issues, etc. No actual code is involved (unless you need to add customization scripts), but you definitely want ex…
It's bad enough when ansible does conditionals and loops with YAML. It's 10x worse when somebody thought they'd made the process easier because you have to drag and drop a box. There comes a point when most of these systems should just hand over control to a popular programming language with decent tooling OR a person and they almost always fly right past it.
All this posts miss the best low code environments of all time: Microsoft Access and FileMaker Pro. Unfortunately these two never made it to Internet era in big time and we have greatly come down from 90s RAD movement.
Lotus Notes was the greatest no-code environment of all. Far, far ahead of its time.
[0] ironically, the one thing we didn't use Notes for was email.
The thing I'm finding hard to get my head around is people who are arguing that various languages such as COBOL or Python are, or might be considered low code or no code. To anyone who needs to hear this: if it's code based programming then it's not no-code or low-code - it's code. Put more simply: code != no-code
https://www.christies.com/lot/lot-a-sumerian-clay-cuneiform-...?
By the way,do you think anybody will pay that much for an 4000 year old Excel Sheet about let's say pork belly futures in that 4000 years?
I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards. Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code…
No code will often make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things.
I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.
I think that no/low code is the secret end goal for any B2B line of business product. You eventually want to be able to have sales engineers directly setting up your products for customers, with developers standing by to support or enhance the shared code pile. You never want to be in a situation where you need 1 developer and code pile per customer when you are trying to capture an entire market segment with hundreds or thousands of businesses.
Once you figure out all the likely paths through the jungle, you can expose configuration and scripting at the various decision points.
Our specific flavor of "low" code leverages SQL and projections of business state to allow for very precise tuning of certain logic. Being able to employ SQL to solve problems implies a very intimate understanding of the problem domain. You have to do battle with the business and iterate the model until you know 99% of it will never have to change. Anything less than this is walking across quicksand, as changes to schemas per already-configured customers quickly turns into a nightmare factory of regressions and otherworldly suffering.