Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Makefile I use with JavaScript projects

olioapps.com

Post reply on HN
Print view View original

251–260 of 525 posts

Re: The Makefile I use with JavaScript projects

#251

Post by hzhou321 »

reificator wrote: post #239
hzhou321 wrote: post #198

Earlier quoted context omitted.

Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as…

Human beings who name things are going to use spaces. That spaces were used as delimiters for computers is somewhere between unfortunate and a colossal mistake. But to use that as evidence of why spaces should not be supported in filenames is putting the cart before the horse. The goal of software is not to perpetuate whatever mistakes have been made in the past. It's to solve problems for human beings. And human bei…

To clarify our views:

The words and sentences are inside the file. The filenames are identifiers to the files. Identifiers' purpose is mainly to identify, rather than to communicate.

On the other hand, we could imagine a user interface that users don't see (actual) filenames at all.

Re: The Makefile I use with JavaScript projects

#252

Post by LukeShu »

jerf wrote: post #104
jofer wrote: post #58

Earlier quoted context omitted.

Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are…

"In all seriousness, what's wrong with it?" 1. Claiming a rule makes a target, but then fails to make that target, ought to be a runtime fatal error in the makefile. I can hardly even guess at how much time this one change alone would have saved people. 2. String concatenation as the fundamental composition method is a cute hack for the 1970s... no sarcasm, it really is... but there's better known ways to make "templ…

> I have read the description of what INTERMEDIATE does at least a dozen times and I still don't really get it.

It took many reads, but I think I get it.

As a toy example, consider the dependency chain:

   foo
Depending on how we wrote the rules, foo.o may automatically be considered "intermediate". If we didn't write the rules in a way that foo.o is automatically considered intermediate, we may explicitly mark it as intermediate by writing:

    .INTERMEDIATE: foo.o
So, what does "foo.o" being "intermediate" mean? 2 things:

1. Make will automatically delete "foo.o" after "foo" has been built.

2. "foo.o" doesn't need to exist for "foo" to be considered up-to-date. If "foo" exists and is newer than "foo.c", and "foo.o" doesn't exist, "foo" is considered up-to-date (if "foo" was built by make, then when it was built, "foo.o" must have existed at the time, and must have been up-to-date with foo.c at the time). This is mostly a hack so that property #1 does not break incremental builds.

These seem like useful properties if disk space is at a premium, but is something that I have never wanted Make to do. Rather than characterizing it as "a hack on the fact the underlying model isn't rich enough", I'd characterize it as "a space-saving hack from a time when drives were smaller".

----

If, like me, you don't like this, and want to disable it even on files that Make automatically decides are intermediate, you can write:

    .SECONDARY:
Which tells it 2 things:

a. never apply property #1; never automatically delete intermediate files

b. always apply property #2; always let us hop over missing elements in the dependency tree

I write .SECONDARY: for #a, and don't so much care for #b. But, because #1 never triggers, #b/#2 shoudn't ever come up in practice.

Re: The Makefile I use with JavaScript projects

#253

Post by lykahb »

Make has dated syntax and conventions. When developers use emojis in command line, support for the spaces and other quirks look worse than a decade ago. Despite all of its expressive power and speed, Make is not going to attract many frontend developers.

If the concepts behind Make are repackaged in a more hipster way, the resulting tool may get far more appeal. Shake https://shakebuild.com is a build system library that can naturally express even the dependencies that require Makefiles go meta and generate new Makefiles. It can be a robust backend for any build system DSL.

Re: The Makefile I use with JavaScript projects

#255

Post by com2kid »

hzhou321 wrote: post #244
Chlorus wrote: post #238

Earlier quoted context omitted.

Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI... But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.

> Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly ... Just to clarify on what we think as problem could differ: C:\Users\hzhou>ls *.txt new 2.txt C:\Users\hzhou>ls new 2.txt ls: new: No such file or directory ls: 2.txt: No such file or directory

dir works fine for that.

:)

I actually didn't know that dir supported multiple globs for filenames! I've never had a need for that.

Super cool.

Re: The Makefile I use with JavaScript projects

#256

Post by monsieurbanana »

lykahb wrote: post #253

Make has dated syntax and conventions. When developers use emojis in command line, support for the spaces and other quirks look worse than a decade ago. Despite all of its expressive power and speed, Make is not going to attract many frontend developers. If the concepts behind Make are repackaged in a more hipster way, the resulting tool may get far more appeal. Shake https://shakebuild.com is a build system library…

I like functional programming languages and Haskell is something that interests me.

But you can't be serious when you say that make is out-of-touch with the average frontend developer, and then link to this:

https://shakebuild.com/manual

Re: The Makefile I use with JavaScript projects

#257

Post by reificator »

hzhou321 wrote: post #251
reificator wrote: post #239

Earlier quoted context omitted.

Human beings who name things are going to use spaces. That spaces were used as delimiters for computers is somewhere between unfortunate and a colossal mistake. But to use that as evidence of why spaces should not be supported in filenames is putting the cart before the horse. The goal of software is not to perpetuate whatever mistakes have been made in the past. It's to solve problems for human beings. And human bei…

To clarify our views: The words and sentences are inside the file. The filenames are identifiers to the files. Identifiers' purpose is mainly to identify, rather than to communicate. On the other hand, we could imagine a user interface that users don't see (actual) filenames at all.

Identification is a form of communication.

The identifier assigned to me at birth contains two spaces. Most people use one of the shorthand forms, but still.

Re: The Makefile I use with JavaScript projects

#258

Post by com2kid »

hzhou321 wrote: post #246
com2kid wrote: post #243

Earlier quoted context omitted.

> it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. There is nothing beneath the Windows UI interface. The GUI is the primary subsystem of Windows, the command line is a separate subsystem. Windows has traditionally been built up around the Win32 API, which is GUI first. It is of course possibl…

> There is nothing beneath the Windows UI interface. To clarify, beneath the GUI interface is the actual code that implements that interface. > Something working so well that it becomes an appliance isn't a bad thing. Not at all. I don't attempt to call or think my phone as an computer. Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances. It is just that th…

> Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances.

It seems that 90% of computer use has moved into the web browser. Heck outside of writing code, almost everything I do is in a browser, and my code editor of choice happens to be built as fancy skinned web browser...

> To clarify, beneath the GUI interface is the actual code that implements that interface.

I'd say that everything moving onto the web has once again made the code underneath it all accessible to the end user, if they so choose.

(Ignoring server side)

Re: The Makefile I use with JavaScript projects

#259

Post by swsieber »

bpicolo wrote: post #123
bitwize wrote: post #107

Earlier quoted context omitted.

Until a stray space finds its way into your command list indentation...

Every popular text editor handles this already. People manage make, python and other whitespace-specified languages just fine.

FWIW, the more experienced a programmer is, the more likely they are to prefer spaces over tabs.

My pet theory is that the more experience you have, the more likely you are to have worked with Python, which is a lot easier to work with if you just always s/\t/ / (replace tabs with spaces).

Re: The Makefile I use with JavaScript projects

#260

Post by reificator »

gdwatson wrote: post #248
reificator wrote: post #239

Earlier quoted context omitted.

Human beings who name things are going to use spaces. That spaces were used as delimiters for computers is somewhere between unfortunate and a colossal mistake. But to use that as evidence of why spaces should not be supported in filenames is putting the cart before the horse. The goal of software is not to perpetuate whatever mistakes have been made in the past. It's to solve problems for human beings. And human bei…

On the command line, using spaces to delimit words is also quite natural; that's why they get used as a delimiter: mv old-file new-file Spaces separate the verb, the direct object, and the indirect object. Using commas or colons instead would painfully artificial. So the question is whether you will favor naturalness on the command line or in the GUI. It's no surprise that a Unix build tool favors the command line.

True, but on the command line I don't have to worry about the spaces. I'm just going to tab-complete to simultaneously ensure I'm in the context I expect to be in, ensure I'm not making any typos, and save some time to boot.
Post reply on HN