loading...
Cover image for Code creation, try it!

Code creation, try it!

designpuddle profile image Chris Bertrand Updated on ・3 min read

I think we should consider the option of writing code, that writes code for us! Let me explain why.

We love coding, we try to write as much code as possible. LoC is the ultimate measurement of your awesomeness. 😊 But how many of us write code that creates code for us?

We love using tools/frameworks etc to aid our writing of course, but limit ourselves to writing these tools.

I've recently been looking at Storybook to help automate the creation of a demo app for our UI library. Currently, this is a manual task creating pages and implementing the components and variations needed.

I've been told that it's not difficult and doesn't take very long. My first thought was, well why haven't we automated it then?

Related image
But I can sharpen pencils too

Automation seems to have been swallowed by testing. Developers no longer use it as a tool in their arsenal. We’ll happily scaffold using AngularCLI or the alternative! Why not create the scaffolds? Each codebase has a style, and each company does things their own way, so they should create tooling. Let’s end the notion of style guides and lengthy how to’s to follow.

Image result for automation gif

A component has a template and some inputs. You could create a simple config file, be that in JSON, YAML, JavaScript, hell any language you choose that could parse those inputs and create those pages dynamically.

Why do we want to do this ourselves?

Image result for code monkey gif
Anyone can do this!

This sort of grunt work doesn't give us any satisfaction, but writing a tool to do this for us, packaging, styling and deploying it would be awesome. Maybe it's the inherent difference between a web developer and software engineer? I don't know, I've always thought these titles are interchangeable, is this not the case? Is it that JavaScript is not thought of in this way yet?

Yes, Storybook gives us this functionality, and it seems to do a pretty good job at it too. I just worry that we expect everything built for us these days. We seem to have forgotten that we can build them ourselves, exactly as we want. Lightweight, customisable, geared specifically to our use case. Even if we do not, it's at least worth considering no?

I guess this follows on slightly from Bens Post the other week.

How many people do this currently? What are the main positives and negatives from this approach? Would you do it again?

Discussion

pic
Editor guide
Collapse
sampathbalivada profile image
Sai Sampath Kumar

I always had a desire to build something of that sort. Although we cannot write up a program to write the logic for us, there's so much of stuff we write just because we need to.

I'm thinking of a place where we talk with a bot(for instance) and tell it about what need and it builds the UI for us.

Collapse
designpuddle profile image
Chris Bertrand Author

That's a cool idea, I'm sure AI will be doing something along those lines in the not too distant future. Will be interesting to see how it pans out.

Collapse
deepu105 profile image
Deepu K Sasidharan

You should checkout JHipster then.

Collapse
designpuddle profile image
Chris Bertrand Author

There are many tools out there, but have you thought about writing one yourself?

Collapse
deepu105 profile image
Deepu K Sasidharan

Well, I wrote a major part of JHipster :)

Thread Thread
designpuddle profile image
Chris Bertrand Author

Haha, so you did. Sorry, I thought you were trying to push another third-party tool.

So a question with regards to it. Did it start out as an internal tool that was used to create things, that then evolved into something that was decided to go public, or was the aim of this always to be released to the masses?

I'd say the majority of readers don't think the creation of such things is a good idea. Reinventing the wheel etc. What are your views?

Thread Thread
deepu105 profile image
Deepu K Sasidharan

It started out as a fun side project by my friend and JHipster founder Julien Dubois which ended up becoming the development platform it is today.

Collapse
jillesvangurp profile image
Jilles van Gurp

I think that just about sums up the npm ecosystem. Many poorly reinvented wheels, me too libraries, etc. How about building better tools?

Collapse
designpuddle profile image
Chris Bertrand Author

Or contributing to these poorly reinvented wheels to make them able to roll properly?

Collapse
jfrew profile image
Info Comment marked as low quality/non-constructive by the community. View code of conduct
jfrew

Super low quality article. Any real software developer, and anyone with any practical experience would tell you that more code = more problems. Larger codebases are significantly harder to maintain and they're practically impossible to confirm to be secure. The smart, forward thinking experts at the top of the field are coming out to the exact opposite message, that you should be simplifying and removing code.

Also, a discussion of code that writes code and no mention of Lisp? Are you even trying?

Collapse
designpuddle profile image
Chris Bertrand Author

I agree more code = more problems. If you automate code using lisp or any other language, there is actually less chance of it going wrong! This does depend on what you’re doing with it.

I’m not completely in agreement that your own code will be worse off security wise or in any other way than using several dependent open source projects. If simplifying your own code, means pulling in thousands of other lines of people’s code, then that has its own implications.

Thanks for the feedback, I’ll take it on board for my next piece.

Collapse
jfrew profile image
jfrew

I shouldn't have been rude to you, I can make a better contribution than being mean.

So, I am not suggesting that we bring in third party libraries to do stuff instead of writing it ourselves. While I believe we should be careful about which wheels we reinvent, there are some wheels that are plenty over engineered. I still count any library used to support code that I've written as part of the codebase's total size. I like that you put forth the classic axiom of Don't Repeat Yourself, but I think that generalizing it to actual production is increasing the complexity, which directly increases the likelihood of error. So, sure, build practical tools. But emphasis on practical.

Also the idea that high LoC is a positive indicator is straight wrong thinking. Increasing the complexity of a system increases its chances of failure. Nobody who writes secure software thinks that big is better.

Rereading it, is your piece about tooling or automation? Code that writes code, like with metaprogramming and macros, is not the same as a function that spits out a preconfigured webpage.

Thread Thread
designpuddle profile image
Chris Bertrand Author

Not a problem, it wasn't taken to heart. The LoC line was tongue in cheek, do you not keep a tally of where you're at? 😊

Exactly practical ways of not repeating yourself are important to be aware of, this is potentially one of them. Not to be used too frequently, but definitely, in my opinion, more than we currently do.

Collapse
foresthoffman profile image
Forest Hoffman

I also strongly disagree with the notion of automation just because we can. However, this is a positive and constructive community. Your comment was neither. Please, don't make comments like this. If you have something to add to the conversation, feel free, but that doesn't including flinging insults. Here is Dev.to's code of conduct: dev.to/code-of-conduct. Please read it thoroughly. Cheers.

Chris, this is an interesting article. Nice! I worked with CMSs and automated templating systems for several years, e.g. WordPress. I too thought, "why aren't we automating the generation of these things?" The caveat that I found was, the automation software is always more complicated than actually just creating the product. It takes more time to create potential variables, rather than a polished and focused result. I actually wrote an article a long time ago called, Abstraction for the sake of Abstraction. In the article, I talked a bit about this, but focused on automation tools in the JavaScript ecosystem.

Collapse
designpuddle profile image
Chris Bertrand Author

Hey Forest, I agree we shouldn’t do it all the time; the notion was to explain that you can if you need to. I’ve worked with some internal tools/generators that have been a godsend. There are definitely positives to the approach, and they were what I was trying to highlight.

Collapse
jfrew profile image
jfrew

Sorry, I definitely came on way too hostile.