I too have 40+. I have to admit, unlike most of my modern peers, I have not followed industry standards too closely. Don't get me wrong. I like them. I think they're important. And I try to follow them as much as possible. The problem I have run into time and time again is the limitations they impose. Let me give some examples:
1. Back in the early '80s, most developed in C. Eventually, C++ came out. Like others, I was very excited about OO and C++. I finally got a hold of C++ and was utterly disappointed. The first problem was its rigidity. Yes, it gives you zero-cost abstraction, but I'd be willing to give up a little cost (speed) for greater flexibility and expressiveness. Nope. The second problem was complexity. Although it was cool to play with, as a new business owner, I feared: a. Hiring developers who couldn't figure out the code - you pay them a salary for months before you figure out they're not getting it. b. Hiring a developer who can figure it out. That is even a bigger problem. The smart programmer works for you for a couple of years and then quits. At that point, their code is so big and complex no one can figure it out. The third problem was compile time. C++ keeps a lot of information in header files. If one changes, as they very often do, all code that uses that class has to be recompiled. On the slow machines of that day, this was a serious problem. Developers were spending a vast amount of time waiting on compiles and losing their mental context. Rather than stick with the standard, C++, I created my own OO extension to C. It solved all of the above problems: a. It was far more dynamic and powerful than C++. Yes, there was a cost, but the cost was far less than just using a slightly faster machine. Several large companies successfully based their entire product line on my new extension (Dynace <https://github.com/blakemcbride/Dynace>). b. With Dynace, you could take a class that existed in the middle of a vast collection of interdependent classes, change it, and that would be the only file you'd have to compile. None of the users of the other classes that used it had to be recompiled! c. Dynace added only the bare minimum in terms of keywords. Syntax was standard C. It came with a tutorial. Most programmers could pick it up in a single day. I have to admit, although a few companies and many programmers used it over the years, I never met a programmer who liked Dynace. For a long time, I couldn't understand this. I talked with many of them trying to understand the problem. Almostall were either unable or unwilling to articulate the reason. After a lot of discussions, I finally figured out what the problem was. The problem was, if they became an expert at Dynace, it wouldn't help them find their next job!I f they used C++, they had the power.They could always find another C++ job. If they used Dynace, the employer had the power. They had a harder time finding a new job. That was the problem. 2. Years ago, the standard for developing Windows applications was Microsoft MFC. The whole world used it. No one I knew questioned it. Creating a basic "Hello World" application in Windows with MFC using their VC code generator created more than 10 files and at least hundreds of lines of code. You then had to strategically edit the generated code to flesh out the application. When you upgraded to the next version of MFC, their advice was to regenerate the application with their code generator and then move your scattered application-specific code into the newly generated code. I thought that was the craziest thing I ever heard of. I couldn't imagine a human doing that. Yet I was wrong. The entire world did just that. When I asked people about it, they just shrugged and told me that's the way it is done. Whatever... I created my own Windows Application Framework in Dynace called WDS <https://github.com/blakemcbride/WDS>. With it, you could create a "Hello World" application in about 4 lines of code. Updates to WDS never required a recompilation, just a relink. A dialog could be added with about 4 lines of code. A menu with 2 lines of code. I even wrote my own resource editor that would allow graphical design of dialogs. And you could change a dialog without having to recompile or relink your applications. A few successful software companies based their entire Windows applications on Dynace and WDS. 3. I got pushed into the browser application world just as everyone else did. At first, with all of the browser differences and limitations and the hokey CGI crap, I hardly paid it any attention. It was a joke. PHP was a way to make a joke even funnier. Eventually, the web became a real thing. There was no more ignoring it. It was quite a jump to go from desktop applications to the web. While there were many tools to do things like frontend code, authentication, communications (SOAP/REST), data persistence, microservices, etc., you had to get each piece and try to glue them all together. The quality and stability of each piece varied wildly. Each had its own philosophy. You had to learn each and figure out how to make them all work together. Also, some were changing nearly daily. It's a full-time job just keeping a development environment together, let alone keeping your application code up to date. It is a nightmare. I eventually wrote Kiss <https://kissweb.org>. It is a single framework for building entire web applications. It includes all of the pieces mentioned above plus more already integrated into a single thoroughly integrated development environment. Kiss comes as a fully running web application out of the box. You can start with nothing but a Java development environment, type two lines of code, and have a fully running web application. After that, due to the way I implemented microservices, a developer can build their application without ever bringing the server down, rebuilding, deploying, and bringing the server back up. Changes in both the front end and backend can be done while the system is running. In spite of that, everything is fully compiled and runs at full speed. Additionally, production systems can be updated without disrupting existing users. Kiss is currently being used in a few commercial applications. It's open-source and free. I built it for my own needs and figured I might as well share it. -- I could go on with many more examples, a few of which I addressed, most I did not. There are many areas where real innovation could occur, but it's not because we're too stuck on the way things are done. NetBeans is a needless example. The point I am trying to make is that while I can make many valid arguments about the benefits of standards, I can also argue that sticking too hard to standards severely limits possibilities. It is my opinion that the software industry is way too stuck on standards. It severely inhibits the possibilities. Blake On Sat, Sep 20, 2025 at 6:04 AM Rob Walker <[email protected]> wrote: > We all have our preferences – and we all have our reasons for them, many > of which don’t gel with others. > > > > Gradle was the first newer generation build tool that gave us a worthy > replacement to Ant on our projects. For myself, and most of the guys I work > with, Maven would be the one we’d have throttled. We begrudgingly work with > it on a handful of OSS libs where it’s the tool of choice. Like I say – > different strokes. > > > > On the topic of the original post – Gradle does a passable job of multiple > source roots, with a bit of effort. In NB it’s not perfect, but it’s kind > of OK if you treat each subproject as standalone with clear divisions and > boundaries, and work with it that way. I tend to do my builds & tests from > standalone command shell windows – all I’m looking for out of an IDE is > graceful handling when editing and highlighting when I (or others in the > team) have wandered off base. Couple of the other guys do more work within > the IDE itself – although at least one of those is also a VSCode fan and > uses both. > > > > (Also been a professional coder for 40+ years, FWIW) > > > > -R > > > > *From:* Stephen Parry <[email protected]> > *Sent:* 20 September 2025 11:43 > *To:* [email protected] > *Subject:* Re: Multiple source roots? > > > > I have to make the case against a lot of what has been said here. I have > worked with different build tools for over 40 years, within hobby, industry > and education, including make/cmake with c++, Maven and Gradle with > desktop, and Gradle with Android Java. The consistent and rigid structure > of a Maven build is a key part of its strength as a build tool. You don't > have to spend three days working out where the crazed code monkey who wrote > the build has put the source for the code component you need to work on. > The build is there to provide simple and clear support for the source code, > not to *be* the source code. > If you allow flexibility but guideline good practice, that good practice > just gets ignored. > As such, it is not sufficient to just ask / advocate for multiple source > roots. You have to be specific. That multiplicity has to be tied to a > stated purpose (jmods, generated sources, multiple apps within a suite...), > so that its use is documented, understood and expected. Some of these > already exist in Maven. Programmer's whim or "future expansion" are not > sufficient reason for allowing the build process to be made more complex. > The compile / build / run functions of an IDE should be the the thinnest > and simplest possible wrapper around the build tool. When you open the > 'makefile', that should be opening the IDE project. That is the great thing > about NetBeans. It has almost become Maven with a UI. That way, if the code > runs in the IDE, command line builds and CI/CD have some chance of working > too. You are one step closer to packaging the working final product, not > hiding build issues behind the IDE. Moving between IDEs is simplified too. > All this requires that the build process is simple and consistent enough > that the IDE tooling can understand it and interface with it. This is also > good for any developer who is novice to the project. > From my perception, Maven's main limitation is messy, poor and poorly > understood support for different configurations and platforms. It is very > Javacentric in that way - write once, run anywhere. Although that is a > compromise that keeps things simpler, it left a gap for Gradle, a tool that > should have been throttled at birth, IMHO. > I agree that JSON would have been more concise than XML, but ini files? > That's like saying Fortran is better than Java or Pascal. A build > configuration is and should be an n-level structure. INI files are at best > three level, if you use multiple files. > Gradle configuration is not declarative; it is imperative code dressed up > as declarative. Converting between Groovy(sic) and Koitlin recipes is not > straightforward and the two are yet more languages that have to be learned, > whereas anyone and everyone already can and does learn XML and JSON. The > greater flexibility in Gradle has led to the minefield where the two > recipes needed for adding a plugin or a library work fine for desktop, but > have no chance of working for Android, because Google do Gradle 'their way'. > Just my tuppence worth. > > > > On 19 September 2025 19:58:05 BST, Ulrich Mayring < > [email protected]> wrote: > > I like multiple source roots as well, but since Netbeans decided at one > point to just be a UI for the chosen build system, it also means that the > build system has to support multiple source roots. Gradle does that in a > way, but it's far from perfect and involves manually editing the build file > - you cannot do it with the “build system UI” aka Netbeans. However, you > can do it well enough to make it work for large and small projects and if > it doesn't work for your project, then maybe your project should be > refactored. > > I'm also for imperative build files, because declarative approaches are > too complex for the human brain and should never be the default. They > should only be employed if they work demonstrably better in a given use > case than imperative approaches (in some exceptional cases they may even be > easier to understand for the human brain). > > It is again possible, if not ideal, to use Gradle for imperative > approaches. You can write imperative code in either Groovy or Kotlin. These > are first-class programming languages, so do whatever you want. However, if > you think a build file should not be executable code, but only > configuration for an external code executor, then Maven might be the right > build tool for you. > > If you want to write your own build tool and use it in Netbeans, you have > to write a plug-in to integrate it. Riding on the back of another plugin > supporting another build system and sneaking your own in there, doesn't > make sense. You'll never get your fixes or changes approved, because that > other build system is probably not interested in supporting piggy-backers. > > iSYS Software GmbH > > Ulrich Mayring | Full Stack Developer > Technology Lab / R&D > > Tel: +49 (0) 89 46 23 28-0 | Fax +49 (0) 89 46 23 28-14 > email: [email protected] > > Grillparzerstraße 10 | D-81675 München > www.isys.de > > Sitz der Gesellschaft: München | HRB 111760 > Geschäftsführer: Stefan Fischer und Max Haller > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
