201–210 of 394 posts
Earlier quoted context omitted.
Hehe, good one! Oh, you're serious? :D
If it's so bad, you're welcome to write your applications in vanilla JavaScript, with no shims, in flat files without modules calling 1998 era DOM APIs. There's a reason most people don't, however.
As funny as this post is to read, I don't want to see yet another developer say "complexity bad". I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down. _THEN_ I want developers from that company to share their opinions about how they do it. Do such companies/products even exist? Software is so bad these…
Jeff Robers and Casey Muratory used to do a podcast called the Jeff and Casey show where they'd occationally discuss software products shipped by RAD.
One such episode details the maintenance of a garbage collector RAD shipped, which Jeff denounces as way too complicated and (IIRC) not worth the developer time or CPU cycles.
Complexity bad.
Earlier quoted context omitted.
Undoing someone's copy-pasted for-loops and while-loops is called "factoring" and undoing someone's bad abstractions is called "re-factoring" and is about 10x as slow. At this point in my career I have seen way more crappy abstractions and needlessly abstracted code than grug-brain code. And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reaso…
> And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reason about. > Sometimes loops are better! That I think is backwards. A loop could be doing literally anything - it probably is futzing with global variables - so there's no way to reason about it except by executing the whole thing in your head. A map (or mapA) or a fold (or foldM) or a fi…
The opposite is true in my experience. Loops working over variables local to a function is a lot easier to reason about then a series of intricately intertwined lambdas, if they share state. If everything you do is functional then a series of pipelines might be alright, but it might not. If the functions are spread all over the place it can take a larger amount of mental load to keep all the context together.
Code should permit local reasoning, and anytime that is obscured, rather than helped by, abstractions, we incur additional cognitive load.
Earlier quoted context omitted.
You are free to develop everything in vanilla JavaScript and run your coded scripts straight in the browser. Very non-complex. But the team that uses npm, babel, webpack etc will crush you both on development speed and stability.
Speed maybe. But stability? Hard to imagine how that stack of build tools is going to provide more stability.
> good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell grug know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no underst…
Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that…
The alternative is setting (sometimes many) breakpoints in different places and remembering what happened at each of them. Personally, I prefer reading a log.
As funny as this post is to read, I don't want to see yet another developer say "complexity bad". I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down. _THEN_ I want developers from that company to share their opinions about how they do it. Do such companies/products even exist? Software is so bad these…
I think maybe Reaper fits the bill. http://reaper.fm/
As far as I can tell, it's two people.
> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs. In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing…
In practice tho, the grass is always greener on the other side. You either wish the developer had just hacked something to get it going, when the feature failed, or you wished they had put more effort to make it more abstract and scalable, when the feature set for scaling.
Everyone's a genius on hindsight. Getting it right is more of a mix of experience, gut feel and luck imo.
Earlier quoted context omitted.
Speed maybe. But stability? Hard to imagine how that stack of build tools is going to provide more stability.
Modularization, encapsulation, coordination, safely scaling contributors/features.
Just `import` and done. No build steps.
Earlier quoted context omitted.
Hehe, good one! Oh, you're serious? :D
If it's so bad, you're welcome to write your applications in vanilla JavaScript, with no shims, in flat files without modules calling 1998 era DOM APIs. There's a reason most people don't, however.