181–190 of 221 posts
Earlier quoted context omitted.
The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready
The problem is you don't have CI Having CI won't stop the developer of the dependency changing the interface.
Earlier quoted context omitted.
I have developed c++ with vim and visual studio for a couple decades. I recently made the switch to vscode from vim and i like it even better than studio. Its snappier and it integrates with my vim workflow well so i dont have to do either or.
I don't see the benefit of switch from sublime to vscode. What am I missing? Does vscode offer something different?
[1] https://marketplace.visualstudio.com/items?itemName=ms-vscod...
Earlier quoted context omitted.
I mean I haven't been a professional for multiple decades but I've written professionally in a very wide range of fields in C, Matlab, Java, Python, Verilog, Assembly, Fortran, and Javascript, and, there is no language that I've seen that has more hair pulling, braindead I just learned to program yesterday type programming nearly as much as I've seen in Javascript. (I've worked intimately with decades old scientific…
I have a similar set of experiences but have a feeling that it's at least partly down to the sheer number of people writing Javascript and the very public nature of much of that code that so much of it is a mess. I don't think there's anything inherent in JS that make is produce messy code other than the fact that it's easy for amateurs to get results (thanks to the fact it runs in a browser and there's lots of easil…
There's half a dozen different syntaxes for importing/exporting functions, creating functions, creating objects, etc., and it's all fair game. Then there's the asynchronous nature, so sometimes it's async/await, and sometimes it's promises, and sometimes it's callbacks, sometimes all happening in the same function.
And then on top of that there's all the front-end web frameworks which are like, totally un-opinionated, man, except for the parts where they're implicitly super opinionated.
Important code needs love, it needs to be improved, made more robust, have security issues handled, consolidated if it starts to bloat, to be cleaned and kept legible even for whitespace so you or the next guy can easily see and continue to look after all the moving parts. If it's important, it needs and deserves all those things; they are not "churn" but maintenance.
Churn kills important code, making it unfit for purpose.
The piece reads like a Unix pastor's pulpit preaching "Great nutritious technologies to use: Make, Emacs, Lisp, CLI" "Bad unwholesome technologies to use: JavaScript, Ruby, IDEs, Graphical User Interfaces" I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. And is it candy or an olive that I like VSCode and not Emacs (not that I've ever tried Emacs, I just don't…
Could you elaborate on how you've been burned by make? Because my experience is the exact opposite of yours. I shudder to remember some of the cmake I've had to deal with.
Earlier quoted context omitted.
Lisp was theory before it was code. Javascript was a fashionable imitation of another popular language dialect.
> In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[16] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include Sun's more static programming language, Java, in Netscape Navigator so as to compete with Microsoft for user adoption of Web technologies and platforms.[17] Netscape Commu…
In early 1996, John Ousterhout stopped by to pitch Tcl/Tk, but it was too late. VBScript was coming, but JS in 1995 Netscape betas got on first and saved us from that dystopia.
>> The Churn is losing a day debugging because a transitive dependency changed a function signature. The Churn is spending a week just to get a project you wrote a year ago to even run. The Churn is rewriting your front-end because a shiny new thing came around. If you think the churn is that then you're lucky. To me, the churn is working for the man. Everything I ever do is for the man. If I could ever reach a point…
You probably already could if you wanted to. Ten years ago I quit my software engineering job and spent 2 years driving from Alaska to Argentina. Recently I quit again and spent 3 years driving around Africa.
When you spend less money, you have a lot more time than you think, and you don't have to work for the man.
Earlier quoted context omitted.
Plain JS, yes. The modern JS ecosystem, however, has an enormous amount of churn. The hot way to do things in JS world five years ago is hopelessly obsolete now.
Well, the list says "JavaScript" so i took it as plain JavaScript. If you care about avoiding churn you can stick with stuff that have proven to remain backwards compatible and plain JavaScript fits the bill.
Accept the churn or be left behind, imo. The best thing you can do to insulate yourself from the pain described in the post (trying to remember how code worked, etc) is to brain dump important things you learn along the way. I've recently begun keeping a TiddlyWiki[0] for every major project I undertake. In it, I keep unexpected things I learned, cheat sheet items, command-line snippets, and longer form entries about…
Great programmers can find virtues in all tools. Hate the player, don't hate the game.