• 2 Posts
  • 51 Comments
Joined 11 months ago
cake
Cake day: August 25th, 2025

help-circle






  • SatyrSack@quokk.autoFuck AI@lemmy.worldBubble 🫧
    link
    fedilink
    English
    arrow-up
    13
    ·
    edit-2
    1 month ago

    Before current AI/LLM shenanigans, there were a lot of “low code/no code” visual programming solutions aimed at allowing novices to write software using little to no code. Visual programming software like Microsoft Power Automate, which provides users with a list of predefined commands which they can drag-and-drop onto a flowchart. When a user clicks the play button, the commands in the flowchart execute in order.

    This sort of system is great for novices, allowing people who do not have experience programming (people like you, apparently) to create simple programs that do useful things. But as a project grows in complexity, so does the need to get into the code itself and tinker around to fix the nitty gritty details. A more experienced developer is going to want to get into the lower functions of the program and find a solution to the problem. But these visual programming solutions do not offer the ability to fix the nitty gritty. You are stuck only refining the high-level details, which is often not enough to solve your problem.

    “Traditional” vibe coding with languages like JavaScript, C++, etc. can potentially work because an LLM spits out actual programming code that ostensibly does something. And if a developer needs to tweak that code to work a little differently, they hypothetically can. Sure, a pure vibe coder will not know what they are doing as they turn the proverbial knobs in an attempt to fix the system. But at least the knobs are there to turn, and turning them in the right way can potentially eventually solve the problem.

    “Vibe code without the code” probably means to speak to an LLM and have it spit out one of those minorly-editable flowcharts. You get the benefits of vibe coding and the detriments of visual programming. You don’t know what to do to fix it, and you can’t fix it anyway because the tools don’t let you.








  • https://github.com/Euro-Office

    Euro-Office liberates the ONLYOFFICE code base

    Euro-Office is based on the ONLYOFFICE Open Source, an AGPL codebase. This code base is being extensively reviewed and cleaned up, with the goal of making it easy to build and contribute to. Why did we resort to a fork, rather than collaborate? Of course, forking should be a last resort. Unfortunately, open collaboration with ONLYOFFICE was not possible, for a number of reasons:

    • Contributing is impossible or greatly discouraged. ONLYOFFICE typically does not review or accept pull requests. Build instructions are unreliable, outdated or just plain broken.
    • The company regularly makes controversial decisions like closing off features in the mobile apps like mobile editing, and the removal of an administrator panel.
    • Lacking transparency. Commit messages, when visible, often just refer to an issue number in an internal issue tracker. There are quite a number of binary blobs and compiled or obfuscated code blobs. Most internal code comments are Russian which makes is hard to work with.
    • The mobile apps are not really open source but just wrappers. Example. The apps have extensive proprietary sections which will need to be re-implemented. Work on this is underway.
    • ONLYOFFICE is a Russian company (despite many attempts to hide this), and nearly all developers reside in Russia. Open Source is a global effort, but current political situation makes collaboration hard and trust difficult to earn. Especially when development is not transparent and open. A lot of users and customers require software that is not potentially influenced or controlled by the Russian government.