Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The “No Code” Delusion

alexhudson.com

Post reply on HN
Print view View original

291–300 of 334 posts

Re: The “No Code” Delusion

#291

Post by spc476 »

solatic wrote: post #88
UserIsUnused wrote: post #19

Earlier quoted context omitted.

Thank god trends like Pulumi and the new AWS sdk is emerging. General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense. Configuration is code not data.

> General purpose programing languages are getting more expressive by the day You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imp…

I use Lua for configuration files. It's easy to restrict what you can do in Lua (I load configuration data into its own global state with nothing it can reference but itself). Plus, I can define local data to help ease the configuration:

    local webdir = "/www/site/htdocs"

    templates = 
    {
      {
        template = "html/regular",
        output   = webdir .. "/index.html",
        items    = "7d",
        reverse  = true
      },
      
      {
        template = "rss",
        output   = webdir .. "/index.rss",
        items    = 15,
        reverse  = true
      },
      
      {
        template = "atom",
        output   = webdir .. "/index.atom",
        items    = 15,
        reverse  = true
      },
    }
When I reference the configuration state, templates[1].output will be "/www/site/htdocs/index.html". And if the base directory changes, I only have to change it in one location, and not three.

Re: The “No Code” Delusion

#292

Post by coffee »

Bartweiss wrote: post #251
coffee wrote: post #226

Earlier quoted context omitted.

> If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible. Not really. As we evolve software development, historically, we've done this through adding new layers of abstraction. Assembly --> C --> Interpreted Code (Java, Ruby, etc...) Why isn't the next layer of abstraction simply what is bei…

> Why isn't the next layer of abstraction simply what is being termed as "No Code" today? Cynically? Because people were also selling "no code" ten years ago, or even further back. I know that sort of inductive argument doesn't actually work. We went through a dozen nonsense models of infections, but germ theory was actually correct in the end. AI has seen frauds and baseless hype since the mechanical Turk, but there…

> Cynically?

No, not cynically :-)

> Because people were also selling "no code" ten years ago, or even further back.

Not really sure it matters when it starts. Sometimes markets aren't ready and products are too early.

What matters is are these solutions providing value to people today, and is it enough value for them to buy/spend time on/etc...

Seems there is enough value today, with a mature enough market, based on the results these platforms are experiencing.

> I know that sort of inductive argument doesn't actually work.

Then why waste time making it in the first place? :-)

Re: The “No Code” Delusion

#293

Post by coffee »

goatlover wrote: post #258
coffee wrote: post #226

Earlier quoted context omitted.

> If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible. Not really. As we evolve software development, historically, we've done this through adding new layers of abstraction. Assembly --> C --> Interpreted Code (Java, Ruby, etc...) Why isn't the next layer of abstraction simply what is bei…

Smalltalk was that next level, but for whatever reasons, the programming community never fully embraced that approach, although some modern environments and IDEs come close.

It doesn't matter. I'm not arguing the chronological order in which layers of abstraction have been created and when, just that this is fact. And if this is fact, why not this as the next layer?

Re: The “No Code” Delusion

#294

Post by axilmar »

I've read plenty of comments about this article the last few days, it has made the rounds in popular sites, and the verdict is the same as the author's.

What's surprising is that no one sees the elephant in the room: the problem with coding is that the abstractions available in coding are the same one offered by operating systems: files, processes, threads, mutexes, sockets etc. These are the wrong types of abstractions for the majority of cases!!!

What we should have instead is data, functions, events and channels.

If we had that, then we wouldn't need to have articles about 'no code', we wouldn't need visual programming tools.

The abstractions we have now only get in the way of programming. They make development really slow. If we had the set of abstractions mentioned above, it would have been a lot easier to create solutions!

I am not saying that the abstractions we have now are totally useless; they are not, of course, because they allow us to make things, but they aren't what we need in most cases.

Re: The “No Code” Delusion

#295

Post by janci »

Visual tools work great for creating models (i.e. entity diagrams). There is no reason why not generate 90% of the typical business CRUD app boilerplate from such model. Also business rules tend to be simple (decision tables, process workflows), no need to "code" these. If they are not simple enough for business user, representation in code will not help, so business rules should be kept simple.

What I lack in visual/no-code environments: easy bidirectional integration.

The no-code environment should be able to call into external service (REST, SOAP) or external library (any language) and represent this call as a Black box. The interface should be simple to be able to easily create the missing functionality in best-suited language for the task. But more importantly, the external implementation should be allowed to use all the powerful high-level abstractions that the no-code environment presents to the user. Otherwise, the external service will need to re-implement many of the useful functions of the no-code environment. You then lose all the benefits of the no-code counterpart and this transition is hard.

Re: The “No Code” Delusion

#296

Post by tonyedgecombe »

sgift wrote: post #152
chrisweekly wrote: post #135

Reminds me of being warned, over 20 years ago, that the viability of my new career as a web developer was in doubt thanks to tools like FrontPage and Dreamweaver.

Frontpage and Dreamweaver ... never before could you produce so much bad code in so little time. And never before did the person who had to clean it up to have any chance of breaking out of the box and change something hate you so much. Especially if said person was you six month later.

I always thought the failure of tools like Frontpage and Dreamweaver was a reflection on the inadequacies of HTML/CSS/JavaScript as much as the tools themselves.

If I want to typeset a book or magazine I'm not going to start by writing PostScript or PDF files in VIM. If I want to design a tool then Autocad is likely to be my starting point. Why should the web be any different, why do I need to learn some arcane text based language when all I want to do is adjust the margins on an image or include some data in a page.

Sometimes I feel this industry is going backwards rather than forwards.

Re: The “No Code” Delusion

#297

Post by lizmat »

zokier wrote: post #199
shadowgovt wrote: post #144

Earlier quoted context omitted.

Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it. It's possible, with many languages, to write IDEs that will make this hard, but I've yet to f…

I'm strong believer, even if that belief doesn't come up often, in structured editing [1] which sort of bridges the gap and makes writing invalid programs impossible, at least syntatically but I don't think adding type level checking is a big jump and I haven't kept up with research so that might already be there. Unfortunately I don't know any successful examples of that beyond research projects that I could point o…

Re: "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously."

Except for the short-circuiting operators (such as || and &&) and the assignment operator, all operators in Raku are just subs with a special name. Adding your own operator to the language is as simple as adding a subroutine, e.g.:

    sub prefix:($value) { sqrt($value) }
    say √9;   # 3

Re: The “No Code” Delusion

#298

Post by yebyen »

BigJono wrote: post #158
lucasverra wrote: post #139

Earlier quoted context omitted.

Isn't the majority of software following this rule ? This is not specific of low/no code environment

Yes it is, but if you're doing the first 90% properly you have a much better shot at mitigating the difficulty of the last 10%. I think there's some vague point in any project where it goes from being 'easy' to 'hard' to add new stuff. Basically the only factor that matters for productivity is how long you can delay that point. If you just do the first 90% as quickly and cheaply as possible, you're just resigning you…

I think this is best explained without exaggeration by the famous Design-Stamina Hypothesis[1], which states the notion that time spent on Design is something which you can trade away to improve development speed, is reliably false in the long-term (even if it seems to be working in the near term.)

The graphic also suggests that there is an inflection point, as you suggest, before where time spent on design really is just slowing you down in the beginning of your project, but also that the costs of waiting too long to switch modes (from doing no design, to doing good design) after you have crossed that line, are substantial and compounding; the longer you wait, the more your lack of good design costs.

And of course, not pictured, is "bad design" which can be even worse than no design. Trying to find that inflection point and put it on your development schedule in advance is also a bit like trying to catch a falling knife (not likely to succeed.)

[1]: https://martinfowler.com/bliki/DesignStaminaHypothesis.html

Re: The “No Code” Delusion

#299

Post by l4r5 »

I use this metaphor: If you only learned 50 words from a new language, that may be enough to have a great 2 week vacation but it won't be enough to actually life somewhere else and do successful real legal business.At least it will be quite hard to do so.

Learning a language to be able to do that will take some time and training. But once you learned it, life will be much more easier and success will be easier.

Computer languages are called "languages" for a reason.

Re: The “No Code” Delusion

#300

Post by chrisweekly »

sgift wrote: post #152
chrisweekly wrote: post #135

Reminds me of being warned, over 20 years ago, that the viability of my new career as a web developer was in doubt thanks to tools like FrontPage and Dreamweaver.

Frontpage and Dreamweaver ... never before could you produce so much bad code in so little time. And never before did the person who had to clean it up to have any chance of breaking out of the box and change something hate you so much. Especially if said person was you six month later.

Frontpage was awful, but I felt Dreamweaver did a pretty reasonable job generating markup. At least in comparison to FP, it was a radical improvement.
Post reply on HN