Live data from Hacker News

The Makefile I use with JavaScript projects

olioapps.com

501–510 of 525 posts

Re: The Makefile I use with JavaScript projects

#501
post #165

Earlier quoted context omitted.

Before C was invented there were already other companies writing OSes in high level languages, but yeah thanks to its victory now it gets all the credits. History is re-written by winners as usual.

I wasn't thinking in terms of winners. But what were those other OSs and languages? Sounds interesting!

You can start here,

https://en.wikipedia.org/wiki/System_programming_language

https://en.wikipedia.org/wiki/Category:Systems_programming_l...

Some examples, out of my head.

- Burroughs, now being sold as Unisys ClearCase, used ESPOL, later replaced by NEWP, which already used the concept of UNSAFE code blocks;

- IBM used PL/8 for their RISC research, before switching to C, when they decide to go commercial selling RISC hardware for UNIX workstations

- VAX/VMS used Bliss

- Xerox PARC started their research in BCPL, eventually moved to Mesa (later upgraded to Mesa/Cedar), these languages are the inspiration for Wirth's Modula-2 and Oberon languages

- OS/400, nowadays known as IBM i, was developed in PL/S. New code started to be replaced by C++. It was probably the first OS to use a kernel level JIT with a portable bytecode for its executables.

BitSavers and Archive web sites are full of scanned papers and manuals from these and other systems.

Re: The Makefile I use with JavaScript projects

#502

Earlier quoted context omitted.

>But regardless of that, a tool that makes a semantic distinction between tabs and spaces is NEVER the UX you want unless you're a masochist. GNU make has had an option (.RECIPEPREFIX) to change this for a long time now. Stop whining.

This seem downvoted, but I would second the opinion. If you're capable of representing a dependency graph, you should be able to handle the tabs. If `make` does your job and the only problem is the tabs, it's not masochism, just pragmatism.

HN has a pretty strong anti-make bias. People here would much rather use build tools that are restricted to specific languages or not available on most systems. Using some obscure hipster build tool means it's a dependency. Though these people who are used to using language-specific package manager seem to take adding dependencies extremely lightly.

Re: The Makefile I use with JavaScript projects

#503

Earlier quoted context omitted.

I once (back in the mid-1980's) spent several weeks hunting down a makefile bug. In the end it turned out to be a SPACE character that preceded a TAB character. It's some weeks of my life I will never get back. I hate make and it's 'entire syntax'.

Back in that 1970's developer's paradise, it was not possible to lose a space next to a tab, because we did not have WYSIWYG editors, we had "vi" which has an easy toggle to show white space characters. "Back in the day" everything had a command line interface, and non-developers were afraid of computers. Ah, the good old daze...

Having been a (moderately power) vi user since the early-80's, Today I Learned about this "show white space" toggle. Thanks!

Re: The Makefile I use with JavaScript projects

#504

A lot of good arguments about using and not using make. Count me in the not using make camp. IMO it's just simply overkill. JS work nowadays is so modular if we were talking about configuring a monolith service at build time... sure yeah. Meanwhile I just wanna make this div purple.

I presume you're running simple small js files. This post is about larger projects that need to transpile newer js code down to browser compatible code, combine multiple files into 2 or 3 http requests, and pack every possible byte out of the js resources we end up sending to clients.

Yup I'm a JS Dev and I use webpack (3). I get the entire thing. However I think this is still all so complicated for no sake but for a small benefit. I'm currently looking for a tool to find out how much is seen/used vs how much is delivered.

Re: The Makefile I use with JavaScript projects

#505

Earlier quoted context omitted.

http://githut.info/

There's way more to software engineering than GitHub. Example: every company that hosts their own code repositories. The TIOBE index, while not entirely accurate either, does reflect usage by a much more broad set of engineers.

Incorrect. TIOBE shows you what companies are making their employees do. Github numbers show you what programmers actually want to do.

However, looking at job ads these days I hardly see any for C relative to JavaScript.

Re: The Makefile I use with JavaScript projects

#506
post #20
post #2

One thing I've found useful about gulp and webpack is the fact that it's multiplatform. What is the best approach to make sure your Makefile will work as expected on every platform, meaning, windows included? For example: Can we write file paths using forward-slashes, or is it still an issue? I imagine running it via git bash (bash provided by the git installer on windows).

CMake! No, I'm kidding, don't really use CMake...

Downvote?! Looks like we have a CMake fan...

Re: The Makefile I use with JavaScript projects

#507
I learned a lot from this, and whether or not one should be doing this, I simplified:

https://github.com/shmup/react-makefile/blob/master/Makefile

I opted out of checking for modification dates on node_modules and yarn.lock, because that seems like exactly what Yarn itself is for. I let it manage itself.

I also let Webpack do the heavy lifting.

So in short: I don't really need the Makefile at all and could just add the clean and dev-server commands to a script block in package.json

I still like it though

Re: The Makefile I use with JavaScript projects

#508

Earlier quoted context omitted.

There's way more to software engineering than GitHub. Example: every company that hosts their own code repositories. The TIOBE index, while not entirely accurate either, does reflect usage by a much more broad set of engineers.

Incorrect. TIOBE shows you what companies are making their employees do. Github numbers show you what programmers actually want to do. However, looking at job ads these days I hardly see any for C relative to JavaScript.

My point was that TIOBE is simply more all-encompassing than GitHut. It gives you a clearer picture of the most searched programming languages, which includes both GitHub as well as non-GitHub stats.

Also, GitHut counts repositories, not lines of code. Not sure which of C or JS has more lines of code being written every year, but my guess is that it's C (Java might have more than both though).

Re: The Makefile I use with JavaScript projects

#509

Earlier quoted context omitted.

Incorrect. TIOBE shows you what companies are making their employees do. Github numbers show you what programmers actually want to do. However, looking at job ads these days I hardly see any for C relative to JavaScript.

My point was that TIOBE is simply more all-encompassing than GitHut. It gives you a clearer picture of the most searched programming languages, which includes both GitHub as well as non-GitHub stats. Also, GitHut counts repositories, not lines of code. Not sure which of C or JS has more lines of code being written every year, but my guess is that it's C (Java might have more than both though).

Yes and my point is that GitHub numbers show you a much better picture of programming languages that programmers actually want to use.

Are we just going to go back and forth saying the same thing over and over though at this point?

Re: The Makefile I use with JavaScript projects

#510
post #431
post #82

Earlier quoted context omitted.

In case you didn't know, the 80 column limitation has its origins here https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_pun...

Interesting. How why the size of the card affect the size of the screen? I have assumed that it was kind of a good number for size of screens at that time.

It most probably wasn't a limitation so much as a convention carried over from one generation of technology to the next in order to ensure the adoption of the latter.
Post reply on HN