5 ms·

The idea is not to automate software development, the idea is to automate the writing of it. Meaning it is not the logical part you want out of the equation. W

• nlitened 5y ago
  You don't need to write boilerplate code and watch for syntax errors, if you use a programming language that does not encourage boilerplate or have a lot of syntax. When I start a new C# project, first 40 minutes I am mindlessly writing a scaffolding of classes, data structures and helper functions that I will need from the beginning. When I start a new Clojure project, I don't need all that, so I just stare at my blinking cursor thinking about what the program will actually do.
  • Pandabob 5y ago
    Can you expand on this? Let's say I want to write a backend with Clojure, wouldn't I still need to write boilerplate for auth, the api endpoints and the CRUD operations?
    • diatone 5y ago
      If I understand correctly, GP wasn't necessarily stating that Clojure guarantees an absence of boilerplate for every use case, but instead that it doesn't require boilerplate to be written every time you use it. I'd encourage looking through the documentation for Luminus[1], one framework for writing web apps Clojure, to help you figure out if it suits your personal tolerance for boilerplate. IMO the example for gating API endpoints by authentication[2] is remarkably simple, but you might prefer something more opinionated a la Rails to completely abstract the auth boilerplate away. For what it's worth, being a lisp, Clojure could certainly support a framework for writing web apps that's highly opinionated, and takes in config for tweaking some defaults (e.g.: auth), thanks to macros. [1]: https://luminusweb.com/ https://luminusweb.com/ [2]: https://luminusweb.com/docs/services.html#authentication https://luminusweb.com/docs/services.html#authentication
      • deleted 5y ago
        [deleted]
  • moonchrome 5y ago
    >When I start a new C# project, first 40 minutes I am mindlessly writing a scaffolding of classes, data structures and helper functions that I will need from the beginning. I share this sentiment but the recently announced changes to file level namespaces, global imports, top level definitions etc. have the potential to eliminate a lot of pointless boilerplate. Now the structural patterns - those are self inflicted - you pay that cost to keep the thing consistent and maintainable down the line - but people often can't evaluate when it's not worth it (and often even don't understand what they are try to achieve but instead treat it like boilerplate that has to be present)
  • osigurdson 5y ago
    In my experience, the first 40 minutes of a project's lifecycle is largely noise. It is much more important is to create a body of code that can be effectively grown by large teams of developers. At the risk of sounding obvious, consider creating a library in situations where you need to use C# if you find yourself doing the same thing over and over again. Of course, if you can be specific about your misgivings that may help the C# (and Clojure) ecosystems or at least help us understand what you mean.
  • akra 5y ago
    I think this equally applies to languages that are more geared to REPL and/or scripting development (e.g. script languages and/or functional languages). Not just Clojure. OO requires a bit of boilerplate and structure up front IMO, at least the Java/C++ variety. IMO the structure typically has to be re-invented each project as well. i.e. what factories, interfaces, parts will I need?
• max_ 5y ago
  I agree with this perspective. I think people seeking to automate software development should find out a way of compiling something like TLA+[0] to executable code. Right now coders are both masons(brick layers) & architects. TLA+ is what can bee seen as a "blueprint" for code, and the actual code can be thought of as the brick and mortar. Devs having to only focus on the blueprint of the code i.e specifications written in TLA+. Truly takes the industry forward. [0]: https://www.youtube.com/watch?v=-4Yp3j_jk8Q https://www.youtube.com/watch?v=-4Yp3j_jk8Q
  • ithkuil 5y ago
    > Right now coders are both masons(brick layers) & architects Not sure how common this is today, but I do remember the time when software development was done by people writing hundreds of pages of specifications of various level of detail (including class diagrams, method names etc) and then delegating the menial work to very junior folks. In many cases I witnessed true contempt for the mere job of transcribing programs. I'm not talking of some dark age of punchcards; but clearly learning the boring details of the Java SDK and figuring out how to setup your Eclipse project (let alone using CVS/SVN) was deemed to be below the pay level of many. The quality of the software produced in those environments was abysmal. I'm not talking about specs on general, but the practice of making the mistake of overspecifying to the extent you think you need a quasi-mechanical transcription (an undergrad student or a very junior dev) but at the same time not really specifying everything and thus le
    • OldOneEye 5y ago
      It's a shame your message got cut. I remember having the same experience during my third job, in a french consultancy in Spain. For the sake of vindication (so many years after the fact xDD) I will just name it: Sopra [0]. So, for each business task (like adding some feature to the application we were developing), "Analysts" would write the "specification" in uml-like models in Eclipse (some kind of modelling plugin for Eclipse, I think it was a framework developed by the company over the EMF plugin suite), and a very short description of what this was supposed to accomplish, business-wise. Our[1] task would be, then, to generate a scaffolding from these models (via Eclipse) and then to fill in the blank of the methods generated this way. The problem lay at how the incentives were laid in that company (and many others like it, the whole IT "consultancy"[2] business, in fact) : Programming was a job that was poorly paid (but still, much higher than the median salary in Madrid, which is why I was there). So, every person had every incentive to get to either management or higher "design" roles (Technical Analyst, Business Analyst, Architect) as soon as possible. This meant that the people who remained in the company[3] were either the people that had 1 year, 2 year tops, of programming experience that got to now design whole systems and applications, or the sociopaths that floated to management by stabbing everyone on the way up. You can imagine the quality of the systems produced this way... Models were hilariously under specified, and clearly the person doing them did not have experience on how programas behave in real life. But because they were so insecure in their positions (remember the backstabbing and the lack of experience), any back and forth between the programmers and the analysts was handled with hostility and contempt from the analyst side. Obviously we also looked at analysts with contempt. Still, they were paid better than us, so of course they were right and they had management support, and were told by our team leads to make it work anyway, so it was common to implement something completely different under the scaffolding, to avoid having discussions with the analysts, that checked that the scaffolding itself did not deviate from their designs. So, my take in this kind of 5th generation (as they were called back then) code generation frameworks is that it encourages the kind of behaviour I saw. And when the same people that do the design also do the programming (the mason architects coders of our time [4]), this way of working is just redundant. Diagrams and models have their place in documenting a project, but certainly not in trying (and failing) to specify everything that can happen in a system. Wow...I've almost written a blog post xD ----- [0]: What a shitty place to work in, at every level. No joy was possible in that environment. Sociopaths thrived and naturally floated to the management positions. As we say in Spain: shit always float to the top. I have so many stories to tell of that place...and I was only 6 months there! [1]: lowly paid and lowly valued programmer-monkeys, literally the term they used when they thought we couldn't hear it (and for a more colourful spanish variation of it: "picatas" which was a derogative term meaning Typist)...how the tables have turned since then... [2]: As we all know, it's just a sham. We were never consultancies, just the equivalent of cheap sweatshops for our french overlords, who came to Spain because programmer's salaries and labor rights were lower than in France. Still...they offered better salaries than the native "consultancies", so there's that. A common theme in Spain, actually. At least foreign exploiters treat labor better than our own national exploiters. The situation has greatly improved since those times, and you can find genuinely good (foreign) companies to work at, in Madrid or Barcelona. The consultancies still exist, but they're no longer 100% of the job market now. [3]: Because, naturally, the churn was stupidly high at the "picatas" level, who could find better offers and situations just by changing jobs every 6 months, which I did. I remember at that time how they tried to FUD us into "loyalty" by saying that they did not recruit people that had this kind of job-hopping CVs. It was false, of course, they were desperate to find people, so they took what they could. My father said the same to me. I don't doubt that was how it was at his time. That era of employee and employer loyalty had long passed by that time, if it ever really existed from the employer side in the first place (I doubt it, IMO it's just that employees had even less choice and were educated by society into loyalty for your task masters) [4]: I'm very glad of how the industry has evolved, job-wise. These times are much more interesting from a technical point of view, than what existed in the past. I get enjoyment out of my job now, and that is priceless. Also the high salaries help. Not as high as outside Spain, of course, but high enough for a good life.
• victor9000 5y ago
  Except reading software is harder that writing software, so it actually makes my job harder (and less interesting) if my responsibility changes to debugging machine regurgitated code.
  • IggleSniggle 5y ago
    Back to writing asm for you! Come on, higher level languages are frequently a net win for everyone.
• agent327 5y ago
  So your idea is that, rather than type in the programs directly, we instead switch to some kind of language for defining the program in? A language that abstracts from all the low-level details? Sounds like a winner to me. Somebody should implement this!
  • drevil-v2 5y ago
    I think you are on to something.. Such a language could perhaps even have a formal specification? Like a syntax and schematics?
    • pan69 5y ago
      Yeah, like a Unified Modelling Language.
    • osigurdson 5y ago
      There have been quite a few attempts to use a 2D layout to describe logic. While it does work to some extent to problems naturally suited to unidirectional data flow, it is overly limited for general computation. The patterns immediately behind the distasteful (to some) text of code are N dimensional and cannot easily be mapped to two dimensions.
  • KronisLV 5y ago
    There certainly have been attempts to do this to varying degrees over time. For example, in Java, there is JHipster which introduced a DSL to describe a number of application concepts and then generated code based on those: https://www.jhipster.tech/ https://www.jhipster.tech/ The problem is that these approaches tend to fail whenever you need to either edit the generated code while not breaking the generation logic, or implement more complex logic and cases that aren't covered, or even just integrate with external libraries without digging too deep in the generation logic to assimilate the external code within the codebase. Now, there are other, more limited cases in which this can work, especially with frameworks like Ruby on Rails or even Laravel, which provide all sorts of code generation logic for specific situations, given that they're typically not integrated with that many libraries, in which case they just make development faster and simpler. Link to Ruby on Rails generators: https://guides.rubyonrails.org/generators.html https://guides.rubyonrails.org/generators.html (this does mostly describe how to write your own ones, though) Link to Artisan make command (for models) in Laravel: https://laravel.com/docs/8.x/eloquent#generating-model-classes https://laravel.com/docs/8.x/eloquent#generating-model-class... Link to info about MySQL Workbench (both forward and reverse engineering): https://dev.mysql.com/doc/workbench/en/wb-data-modeling.html https://dev.mysql.com/doc/workbench/en/wb-data-modeling.html Personally, i think that there's a lot of utility to be had in this approach, especially for situations like schema-first database development, or even generating migrations based on the model classes within the application. MySQL Workbench actually lets you generate DDL statements based on ER models, as well as synchronizing partial changes in a live database, which is useful in practice, yet also really niche and probably hard to implement behind the scenes. Perhaps that's why sadly model driven architecture hasn't really become all that popular outside of academia. Edit: i've added links to the tools i mentioned above, but also remembered that one of the things i've found most annoying about model driven architecture is that most of the work with models is forwards only - you can only go from a metamodel to a model and never the other way around. Ideally, there would be a way to take the current state of the codebase (with any metadata and also manually changed code) and generate a metamodel that can be changed as necessary, to later generate the model again but without losing the manual implementation.
• TomSwirly 5y ago
  > The idea is not to automate software development, the idea is to automate the writing of it. But they seem the same. > Meaning it is not the logical part you want out of the equation. The "logical part" is what we call "writing software". The rest of it is window dressing. > the bad naming conventions Why do you expect an AI to come up with clearer names than a human can?
• avnigo 5y ago
  I agree, but this also sort of kicks the can down to code review... until that could be automated too. As opposed to building the code from the ground up, maybe we'd have to sculpt it from an amorphous blob into something more refined. I guess coding manually would be something people do as a hobby, like solving sudoku.
  • ordiel 5y ago
    That is sort of how I think it will be. Think about it this way, we (humans) automate all complex tasks since we know we are not that good at managing high complexity at once, code in itself is incredibly complex, no human can truly know all variable names and the location of already existing datastructures, you see this on our day, when 2 devs end up implementing classes for similar purposes just because they were not aware someone else had done it nor how was it named, this even pases code review since 1) sometimes the reviewer doea not know the other class exosts either 2) its not visible from the scope of the code review... Once we acknowledge we also need to delegate software creation to software you start abandoning the idea of a code review for something more alike to "correctness review", basically making testing your code review itself And as you say manual coding would be done either by pleasure, nostalgia, teaching and most importantly identifying possible optimizations and errors
• omegalulw 5y ago
  How long do you _actually_ spend on boilerplate/syntax? Your perception is likely exaggerated as it is tedious work.