(I've worked intimately with decades old scientific programming codebases where the scientists didn't give a single damn about writing cleanly and even that was an order of magnitude more readable than the willy nilly, consistency be damned crap I've been seeing in Javascript)
(I feel like I could describe a small portion of hell for me and it would include Javascript)
As for me, I've only recently entered the JavaScript game, but the php I've seen has been much, much worse. I find the quality of JavaScript I typically encounter is on-par with typical Python code, and a fair bit better than the Frankenstein monsters of dev-ops code that often has a different convention for each line of bash (with attendant third-party applications) mixed in with inscrutable environment states as you shift in and out of various orchestration layers that have zero sense of application hierarchy or even running processes.
I've seen scientific codebases too, but the thing you're getting there is an authorship that is often small-team (1 or 2) and very slow to shift, with highly enculturated domain context. Of course JavaScript code is going to be a mess in organizations where you have devs coming from vastly different contexts and staying a max of 2 years with a team where all you care about is getting the pretty graphic on the screen.
But who is writing it and why they are writing it are inextricably linked with the language. Every language has a culture and a reason for existing, those are pressures that bear as much on the person writing the language and the code produced as much as the person writing the code does on the code and the language.
Whether or not say, modern Java encourages good code is neither here nor there, as not only is there resistance to learning new things there is resistance to using the new things properly. Java has a history of bloated, inefficient code for a reason, and when you use Java, the abstractions you use will alter the code that you write. It's impossible to get away from 'bad code' without rewriting things, and then you're not coding your new project you're rewriting someone else's. It's also 'good practice' to use x y z language idioms, but there are cases when such idioms make the code much harder to read and much less clean.
As an example from C: I like POSIX, but dirname and basename are two ridiculously shit functions. If I choose to use them, the rot starts infesting my code, and everything that deals with them has to account for that, which itself causes a bias towards more obtuse code.
Good languages kinda enforce some kind of basic rules, and prevent developers form making silly mistakes - because we all do them all the time. Those languages usually trade off the performance for safety though.
We should pick the safest language, that prevents errors and mistakes as long as we stay within allowed performance bounds.
JavaScript can be performant, but most of the times it isn't and it isn't safe at all. At least we have typed variants of JavaScript.
JavaScript by design was meant to fail gracefully - in the background - so the site works fine. Sadly nowadays sites are so JavaScript heavy that it isn't helping at all.
I generally prefer statically typed languages just because there is less ambiguity and function definition can help you greatly - you know what you put it, and what it returns.
With dynamic typed languages unless documentation is pristine(and in JavaScript ecosystem it is pretty varied from package to package) you are out of luck unless you look at the implementation.
bash and devOps code has their own special place in hell. bash has only one advantage - it works on any linux distro out of the box, and that's it. It is unreadable untyped mess.
It's the thing that attracts a lot of new beginners who may or may not be interested in the more serious theory that makes programming what it is.
The core data types actually strike a really excellent balance between representing the major distinct paradigms (named collections, unnamed collections, strings, numbers, booleans) while giving you maximum flexibility within them. Its standard library - array functions in particular - has become very mature. FP and OOP concepts are both quite well-supported, and doing async stuff (client or server or otherwise) with promises just smashes every other language I've used in terms of ergonomics.
Much of the above could be said about Python too, but regardless.
TypeScript and Python (with typehints) are the current favorites. Golang seems to be getting up there for me too, but I don't have enough experience with it to actually be able to say that.
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.
I imagine that accounts for a lot of bad Javascript and PHP code. By the time I wrote any C++ or Python professionally I had a CS degree and a decade of programing experience.
I'm not saying that a language should only offer one approach to a problem, but there should be general guardrails and guidelines. A shared vocabulary. None of that exists in modern JS
- Bjarne Stroustrup
The fact that we have things like the Wayback Machine is a testament to how this approach, while terrible for developers starting out or working in a legacy codebase, has enabled us to preserve what is now a significant portion of contemporary cultural history. AFAIK there is no similar archive of programs for, say, Java or C.
[1] https://standardjs.com/ [2] https://github.com/airbnb/javascript [3] https://prettier.io/ [4] https://eslint.org/
Semicolons could be considered idiomatic or stylistic, for example. Requiring strict equality operators feels more of an idiomatic way to avoid bugs, rather than simply whitespace. Eslint certainly has a number of rules that are more idiomatic than stylistic.
If you're touching on the lack of consistency in, say, open source javascript, I agree, code is all over the place. Also, I think you're looking at a language that has had dramatically more evolution (especially in recent time) than most other popularly used languages. Old code without promises and suffering from callback hell feels archaic.
However, I think if you look at, say, TypeScript repos (which is cheating, I know, it's not javascript), there is more homogeneity, at least from what I've seen.
Of course it evolved. It’s easy to evolve if it was literally nothing in the first place.
It's like if someone took the BASIC my calculator offered back in the day and turned it into a general purpose programming language.
I wonder how many devs are struggling to debug and fix bad code written using Promise and async features. With care you can use these features safely and productively, but it is also very easy to make subtle mistakes that cause intermittent faults or strange corner case errors.
I would argue that anything for phones is similarly braindead.
While the languages are okay, the API's, UI idioms, and general ecosystem seem to have a half-life of about 6 months. If you step away from programming phones for 18 months, it's like you're learning everything from scratch.
(Side note: All right, Groovy should be taken out and shot and the idiot who foisted it on the Android build system needs to be taken to the woodshed and beaten severely.)
I think your beef there should really be with Gradle, or at least, how it is using Groovy. The way Groovy is implemented as a DSL for Gradle is, in my view, toxic. Almost everything is implicit behavior, crucial aspects rely on totally incidental "magical" features that just make things happen when you invoke some cryptic incantation that has an unobvious connection to its context.
Groovy itself is pretty good and IMHO much better than Java for most purposes.
If you were any good 12 months ago - you will pick up any of the trends quite easily in a week or so (partially because you have also predicted the future).
Well, Python does have strong typing. It's just dynamic, not static, and I've seen enough criticism about it to say that it isn't as unimportant as you make it out to be. JavaScript gets a lot of criticism for having dynamic and weak typing. And I think both forms of criticism are valid, though not everybody agrees, which is fine too.
The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess.
So when you go to update the tooling, you find out that this supermake is (a) a commercial project, (b) the company has gone out of business, or adopted a predatory per-seat licensing scheme, or no longer supports your platform, or has changed the product so significantly that you might as well port everything to a different version of make anyway.
Never happened to me.
Common make fail #2
I was regularly dealing with bugs in multi-million-line makefiles. Make, you see, has no debugger; you can't step through things to find out what's going on. To debug an issue you insert print (echo) statements and look at output, and/or gronk through many, many lines of make's internal structures. Why didn't file A compile, and why file B compile twice? It could take a long time to figure out.
Common make fail #3
"Builds are too slow, we need to speed them up."
So you go parallel. Hey, this is easy. Except for those libraries there (they need to be done first). And those headers are generated, so those need to come first, but first first. And everything depends on these libraries getting built, so need to wait for the linker here, here and here. Pretty soon you have a dependency hairball that nobody understands and that people are afraid to change because things always break. Eventually you get to a point where "yeah, building twice usually seems to fix that issue..." and that's when you know the project has grown too damned big for its shell again.
Common make fail #4
You die a little each time that you get screwed by tab-versus-space. And cross-platform . . . umm, what year is it? Then someone smugly mentions some XML-based tool to you, and you snap because that tool is worse in every single measurable dimension and a few more besides but the developer in question doesn't question things because the tool uses Holy XML and Blessed Java (well, some version of Java, anyway, you can probably still download it from somewhere) and who cares if it's just the same set problems with a different color paint slapped on top and the usual Reddit community dedicated to the elimination of all heretical views. Support? Who needs that, just read the source.
Seriously, I haven't seen any build tools in the past 30 years that have done a great job and that were a joy to use. CMake, Ant, Gradle, make-of-the-month-club, whizzy vendor-locked tools, bespoke in-house constructions, they have all been terrible. I see little hope, entropy has won this one.
Not starting by reading the manual, and then writing an idiomatic make file.
Once you understand how to use auto generated .d files, you’ll never have a multimillion line make file.
Once you understand the built in lex and yacc rules, you can generalize them to whatever code generator you are using.
The remaining thing (not spelled out in the manual) is to avoid recursive sub make, and to use the include directive instead. “Recursive submake considered harmful” is a helpful paper, but it should have had the subtitle “a practical alternative”, because people cite the title without reading the whole paper.
I've personally only used make for a few projects, and might not be "in the know" about how to best use make, but isn't a multi million (!?) line makefile a sign you should probably break it into peices, or use a different solution?
Multi-million just seems insane to me
Personal feeling is you should have a way of regenerating makefiles.
I guess my point is that make doesn't scale, and unavoidably gets messy over time as each project solves the same problems over and over in different, buggy ways.
make solves problems you get early in a project ("let's get this handful of files automatically built") and doesn't even try to address issues of modern software development, like build parallelism and dependency management. Its facilities for debugging problems are laughable.
Go look up plan9's mk. It's a remake of the program written by the designers a few decades later with everything they learned from it. Not only are the variables idiomatic, and the spaces problem fixed, but you can ask for output at each stage and (IIRC) view the graph that it builds.
Of course you quickly get to million-line Makefiles in bigger projects. In C++, if you depend on stuff like Boost, a single file can easily depend on thousands of header files, and every single one must be tracked by Make.
But of course, nobody in his right mind would write these dependencies by hand. At my dayjob, the core Makefile is 700 lines. These 700 lines do cross-compilation with gcc/clang for various platforms, unit testing, valgrind, cppcheck, clang-tidy, coverage, and several other things. It is completely non-recursive, runs in parallel without problems, tracks all dependencies, and also works on Windows.
Of course this stuff is complicated. Make is very low-level compared to a build-generator like CMake. But if you want a bespoke build system for your project which lets you control every last detail of your build, it is still a good choice.
> grown to a recursively gnarly Turing-complete mess
> gronk through many, many lines of make
Thank you for my new word of the day. It describes exactly how I feel sometimes, dealing with technical debt accumulated over years, Frankenstein's systems where parts are always churning - often for no good reason at all, new but worse in most aspects - it can be exhausting gronking through the layers of complexity.
Then Microsoft got rid of it because InstallShield gave them money. Now you need the super-extra-professional edition of Visual Studio to have anything but the most basic installer, and you need to hire a guy to write InstallShield scripts while he's taking a break from contemplating just how tough it would be to get by on pogey alone, and God forbid you need to change anything because the guy is on a different floor because he's not a real developer, etc. etc.
Have a look at redo[1].
Also, #3 is what make excels in. I'm still to see another tool that is more fit to that kind of thing.
At the end of the day, I don't like make. It's for reason #5: there's no project introspection, you can't group tasks into high level values, update your graph on the fly, or add anything to your target except at the source level. I see this one didn't make into your list. This is one of the reasons those multi-million makefiles exist.
I'd rather deal with a small shell script, or a larger Python one if it can't be small. Yet, autotools are great for system programming.
The most common mistake, by far, is trying to use make recursively (where make calls other makes down a directory hierarchy). That's typically where "builds are too slow" come from, because you end up with a hairball of complex workarounds because no one make invocation actually has the correct dependency data.
I just create a single makefile and treat it like any other program: Add carefully, ensure that the text is clear, etc.
I think that we're going to see more languages with built-in build systems from early-on in the language's development, but that is a doubled-edged sword (works great for your version of WHIZBOL, doesn't work great if you need to interop with other things).
When you (the general "you", please) use a tool wrong, you can look kinda a fool for blaming the tool.
Is this a copypasta?
That's a common misconception, but people often don't understand what make is. Contrary to the intuition, make is _not_ a build system (like, say, cmake), although build systems can be (and often are) implemented on top of make; nor is it a task runner (like rake).
At its core, make is a declarative expert system (with a very sane design and a very quirky rule syntax). Its area of expertise is updating files. I urge every user of make who hasn't read "Recursive Make Considered Harmful"[1] to do so.
I'm curious about VSCode - why that, and not Visual Studio or another full-featured IDE? I've gone from IDE to vim and back, and I have to admit with great sadness that the various little gimmicks an IDE provides (without hand-configuring the damn thing!) make it worth it, particularly since they all allow for vim keybindings to one degree or another.
[1] https://marketplace.visualstudio.com/items?itemName=ms-vscod...
Where do you see that?
My point being: I imagine you could avoid this just fine with javascript. I don’t see this as a technical issue so much as a cultural one—we gave up on vetting our dep trees.
I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or edit a makefile, it’s been a pain looking up the relevant details in the manual, but nothing as severe as what you seem to be implying. Have I just been lucky, working with less complicated projects, or something else?
The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to add new header files to the list of headers, etc) so I had little confidence in incremental builds and was always building from the ground up.
CMake's generated build systems always have correct dependency graphs (i.e. it will only rebuild the bare minimum when you touch a given file) and I've always had complete confidence that my build is clean (since I just created a fresh directory) and that my incremental builds are correct.
This is why gcc/clang have the option to generate Makefiles for the header dependencies for you. Maintaining these yourself is a hopeless effort.
Well actually, CMake is a build system generator - and the default build system it generates is Unix Makefiles. So I assume CMake generates Makefiles with the appropriate automatic dependency detection baked in, I'm not sure.
The important part was that it eliminated human error on our team and we haven't had dependency graph problems since.
AS_SRC = main.S util.s
OBJ = $(AS_SRC: .S=.o)
[...]
clean:
rm -f $(OBJ)Granted, knowing that there’s an error here helped greatly in spotting it; there’s a good chance I would have run the incorrect makefile at least once before investigating.
I've worked around that in the past by creating empty "target files" that are created when a given target is built and which dependencies rely on, but it's not a perfect solution.
I've looked around for a make alternative, but although I like rake, I don't really use Ruby these days, and so dealing with RVM/rbenv and whatnot is sort of a pain and not worth the effort over make.
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.
The ability to have the entire build/build artifacts in a directory completely standalone from the source directories was a huge win.
Because for me, that meant I could have 3 separate build directories - one for my optimized ARM builds, one for my debug (-g -O0) ARM builds, and one for my x86 unit test/coverage builds.
If I modified one file, I didn't need to re-spin 3 clean builds - I just could hop into the one or more build directory I was interested in and incrementally update the builds. Plus, out-of-source builds make building clean as easy as `rm -rf build/` instead of hoping that `make clean` has all the right pattern matching and subdirectory listings to truly scrub the build artifacts.
[1] https://cgold.readthedocs.io/en/latest/tutorials/out-of-sour...
"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 feel like investing in that ecosystem)?
I agree the front end web framework churn is out of control; hopefully it will stabilize over time. But come on, don't just rip on random scripting languages that have been around for 25 years