Lessons learned from writing ShellCheck

&gt; discovering late in the interview process that Apple has a blanket ban on all programming related hobby projects<p>O_o There must be more to it then that. What the hell does anyone do in their spare time at home for fun then?

I want to thank the author for an amazing tool.<p>I&#x27;ve used ShellCheck to catch&#x2F;fix numerous bugs on some mission critical financial systems (that depend on shell scripts!).<p>Added it to pipelines and as a mandatory pre-commit hook in git, so all teams started using it (whether they like it or not).<p>It even caught some places where a rm -rf &#x2F; could happen because default parameter substitutions were not set ( Same as the Steam bug where it would remove your home directory, but on some big financial systems :) )<p>All in all - an amazing tool that saved me from a lot of grey hairs throughout the years.

ShellCheck&#x27;s unique error&#x2F;warning codes and wiki descriptions for every code with the explanations and example are the work of genius.<p>It seems so &quot;obvious&quot; in hindsight but not many other tools are so good.<p>Also, tangentially, this is also so perfect:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;koalaman&#x2F;shellcheck&#x2F;wiki&#x2F;SC2154" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;koalaman&#x2F;shellcheck&#x2F;wiki&#x2F;SC2154</a><p>and, unless somebody proves otherwise, makes me believe that with ShellCheck and using the described conventions a shell script could be better diagnosed for mistyped variables than a Python script can (namely at &quot;compile time&quot; and not during the run).<p>Vidar, your work significantly improved the life of people confronted with shell scripts. Thanks!

&gt; Converting them to a cleaner ReaderT led to a 10% total run time regression, so I had to revert it. It makes me wonder about the speed penalty of code I designed better to begin with.<p>I have heard from other Haskellers that you can sometimes get good performance by hand-rolling an application monad, and then writing out the MonadFoo instances so you get good ergonomics:<p><pre><code> -- Instead of this: newtype App a = App { runApp :: ReaderT AppEnv (ExceptT AppError IO) a } deriving (Functor, Applicative, Monad, MonadIO, MonadReader AppEnv, MonadError AppError) -- Try this: newtype App a = App { runApp :: AppEnv -&gt; IO (Either AppError a) } deriving Functor instance Applicative App where ... instance Monad App where ... instance MonadIO App where ... instance MonadReader AppEnv App where ... instance MonadError AppError App where ...</code></pre>

I had commented in a previous discussion regarding Haskell that a common criticism of Haskell is that it’s lazy evaluation can lead to problems reasoning about runtime performance, a criticism which is repeated here. I wonder if there any resources, whether language specific tooling, or general theory, that could help developers struggling with this. I suppose that flame graphs would be a useful tool to see where your time is being spent.

&gt; I’d also put serious consideration into how well the language runs on a JSVM<p>What&#x27;s a JSVM? I&#x27;m not getting anything from Google that I think makes sense in the context of post.