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

“Hello, (real) world” in PHP in 2017

kukuruku.co

Post reply on HN
Print view View original

131–140 of 144 posts

Re: “Hello, (real) world” in PHP in 2017

#131

Post by tonyedgecombe »

kuschku wrote: post #44

We’ve gone full circle. Truly look at the PHP code in this article, the JS dependency hell here and in the recent JS article. Look at the code. At the environment. At the libraries. Who isn’t reminded of what Java looked like years ago? We’ve come full circle. ------------------------ Now, if one asks why this is, the answer is pretty simple – enterprise products. To build software of a certain scale, certain technol…

There is a subset of programmers who will try and turn every language they encounter into Java.

Re: “Hello, (real) world” in PHP in 2017

#132

Post by shakna »

erlehmann_ wrote: post #110
shakna wrote: post #96

Earlier quoted context omitted.

Those don't seem limitations of make itself, but rather the compiler and linker you use with it... The compiler may know paths, the linker may know paths, the shell might, make might, or you can supply them. I've seen and used nested Makefiles before. These things aren't really make things. If I use tcc, Haskell or Go in my Makefile, then they mightn't apply. If you can write it in Bash, you can integrate it into you…

I think that all of these are limitations of not only make(1), but all utilities that expect dependencies to be fully known before a target is built. What makes you think they are not? How would you solve all three problems I listed using make(1)?

Why should make solve the dependency expectations of what it is building?

If I use pip as part of my buildchain, then it has a series of places it can lookup, or you can supply one. Same with npm, cargo, and even Go.

If instead, I use a tool that has dynamic lookup, then it will only look in those places after the event.

So, if I used make to send a command like:

    $(echo 'require "foo"' > bar.lua)
Then it can lookup those when the lua file is called, later in the process.

So how would this be a limitation of make itself? The limitation only exists in what you call with make... Which could be anything.

Re: “Hello, (real) world” in PHP in 2017

#133

Post by erlehmann_ »

shakna wrote: post #132
erlehmann_ wrote: post #110

Earlier quoted context omitted.

I think that all of these are limitations of not only make(1), but all utilities that expect dependencies to be fully known before a target is built. What makes you think they are not? How would you solve all three problems I listed using make(1)?

Why should make solve the dependency expectations of what it is building? If I use pip as part of my buildchain, then it has a series of places it can lookup, or you can supply one. Same with npm, cargo, and even Go. If instead, I use a tool that has dynamic lookup, then it will only look in those places after the event. So, if I used make to send a command like: $(echo 'require "foo"' > bar.lua) Then it can lookup t…

A makefile consists of rules. Each rule contains a dependency line which defines a target and an enumeration of prerequisites. This means that the dependencies have to be known before the target is built. By design, it is impossible for a single-pass make(1) invocation to derive dependencies for a C program, as dependencies are output by the compiler.

By contrast, redo builds the target first and then records what was used to build it. For example, when compiling a C file with “gcc -M”, gcc will output dependency information. With redo, you normally record those dependencies after the target has been built. With make(1), that information has to end up in the makefile somehow, possibly leading to further builds.

Re: “Hello, (real) world” in PHP in 2017

#134

Post by nkkollaw »

jayflux wrote: post #124
nkkollaw wrote: post #106

Earlier quoted context omitted.

I think all these tools give you structure, though. Every project is setup in an identical or similar way, which makes it easy for other developers to jump in and understand what's going on.

But that loses its usefulness if there's new tools every 6 months. Yes webpack gives me structure today, but there could be a new structure tomorrow. Look at Grunt and Gulp, NPM and yarn....

Not really, you'll still be able to follow what's going on if the project follows an old standard way of doing things, compared to a random or made-up way of doing things.

I had to update a project that used the Gulp-based workflow 2 days ago, and after 5 minutes I knew what I was doing again.

Even if you don't remember you can still look it up, while those who reinvent the wheel seem to never bother documenting their wheel.

Re: “Hello, (real) world” in PHP in 2017

#135

Post by mseebach »

shakna wrote: post #130
mseebach wrote: post #113

Earlier quoted context omitted.

C already does what PHP does. Why do you need PHP? COBOL already did what C does, why do you need C? Assembler is Turing complete. How is assembler quite limited compared to PHP (or C or COBOL)?

All languages have their place, some in history, some in very narrow fields, some in general use. That was not my argument. My argument, was calling make "quite limited". How would you call make limited? The syntax is expressive, and so is the macro access. I never said I wanted to replace or not replace make.

Because "limiting" has a broader meaning than what is merely possible with enough effort. The experience of practically everybody who hasn't already put in the effort to learn make is that they get much further much faster in more modern build systems - indeed, framework specific build systems often do exactly what you need them to do with no or very little configuration at all. That is a feeling of not being limited by the tool.

Re: “Hello, (real) world” in PHP in 2017

#136

Post by neurostimulant »

dheera wrote: post #69
vectorpush wrote: post #42

I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification for using these tools is presented as "it's 2017" and not as a solution to any particular problem. The issue isn't the 2017 ecosystem, the issue is the 2017 programmer's deference to vanity instead of engineering. All these individual tools exist for a reason,…

On a similar note, I always find it ridiculous when I have to do things like apt-get install npm && npm install bower && bower install ... Why can't we just use apt-get and Makefiles for everything? Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?

npm advantage (or disadvantage depending on who you asked) is the project owner has direct control over release cycle. The owner can decide when to push an update and it will be available to everyone immediately regardless of their operating system.

Re: “Hello, (real) world” in PHP in 2017

#137

Post by rosser »

Spivak wrote: post #67
rosser wrote: post #53

Earlier quoted context omitted.

It's called "résumé-driven development."

Well yeah, why would you do anything else? When recruiters and job postings are mostly concerned with what languages and tools you know over software development ability and computer science knowledge why would you voluntarily make your life more difficult?

I believe the term you're looking for is "middle ground".

Re: “Hello, (real) world” in PHP in 2017

#138

Post by WildGreenLeave »

tonyedgecombe wrote: post #125
raarts wrote: post #45

Earlier quoted context omitted.

https://github.com/turbolinks/turbolinks

"When you follow a link, Turbolinks automatically fetches the page, swaps in its , and merges its , all without incurring the cost of a full page load." Is the cost really that high to warrant this?

It prevents the browser from requesting all the external files (CSS and/or JS), so yes, it may be that high.

Re: “Hello, (real) world” in PHP in 2017

#140

Post by khedoros1 »

iiv wrote: post #55
khedoros1 wrote: post #41

Earlier quoted context omitted.

I don't think it's a joke, but I also don't think "tutorial" is the right word either. It seems more like an illustrative commentary on the state of the webdev industry.

I think the word you're looking for is "satire".

That has extra connotations of parody that I was trying to avoid.
Post reply on HN