Alejandro Martinez

BlogPodcastPortfolio Youtube

04 April, 2018🔗 Linked pageDevelopment🕐 3min read

Make is great and it shouldn't exist

Make is one of those tools that I've always been curious about but never had a good change to try it until a couple of years ago. It is a really powerful and convenient tool and in all honesty I just use it as a task runner, I define some names for a set of commands and run them that way.

When I started using it in my projects and sawing all its potential I started to wonder why we have so many tools across each different ecosystem doing pretty much the same tasks.

One great example is Fastlane. Obviously Fastlane is a great and indespsable tool nowdays for every iOS developer. I use it every single day because I've automated with it every step of my deployment and branch management. It contains a bunch of Ruby code that deals with the particulars of my setup and git-flow and it uses the great actions that the community has build to integrate with Apple systems.

But at the end of the day is just a task runner with tons of helper reusable functions and a bunch of code that I've written myself. I can see an alternative version of the history where those tools could just be used nicely with Make.

Obviously Fastlane and other dedicated tooling has its advantages but it makes me wonder if we're just doing it because we're programmers and we love to create new stuff. We probably could be in a better position if instead had a proper infrastructure were we could keep building things on top for years.

Reusability and composition the biggest promises and lies of programming.

But let's not stop too much on Make specifically. Because we can go deeper. The fact that we need all these tools is the real issue here.

The fact that all these tools need to exist is somewhat the fault of the programming languages and compilers themselves, they lack necessary functionalities to build software.

You can compile a single file easily with any compiler, or run a single script with any interpreter. But as soon as you need to involve anything more the nightmare starts. And the compiler just ¯\(ツ)

What if the compiler itself fulfilled all your needs without becoming super complex? Think about it.

This is something that when I saw Jai trying to fix I got really excited. (yeah, surprise Jai again). Is one of the best things that Blow is trying to accomplish with his language.

Jai allows you to simply write code in your program that can access an API provided by the compiler to change compilation settings, manage workspaces and perform arbitrary operations at compile time. Pretty much everything any build tool does you can do it directly in your source code and the compiler will take care of executing it. You don't have to learn a new tool or manage any other dependency.

Imagine a world where if you're writing source code for a language, you have the compiler, and that's everything you need.

Being able to write arbitrary code is one of the exciting things about the Swift Package Manager that uses a Swift source code file to define the dependencies. Recent proposals will make SPM even more powerful allowing other tools to hook into the build process.

That's really neat and very important for the status quo, but still, why we need SPM and we can't work only with the compiler? Even worse, usually for any convenience you still call SPM from tasks in your Makefile.

There are so many things to maintain just to do our work.

Anyway, let's leave it here for today. Xcode finished installing all its required tools and apparently all the Javascript stack finished deploying the compiled code. ;)

👉🏻 If you have any feedback you can reach me at alexito4

Testing an RxSwift operator with TestSchedulerGoogle IO, Android Jetpack and Architecture components

Alejandro Martinez
alexito4@gmail.com

Buka pintu

alexito4
alexito4