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

Hack Isn't PHP

marco.org

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Hack Isn't PHP

#31

Post by orting »

deckiedan wrote: post #18
StevePerkins wrote: post #8

I'm not much of a PHP coder, so I tend to watch these flamewars from a distance on the sidelines. However, I've never really understood why people criticize or mock Facebook for pouring so many resources into PHP. For building cross-compilers, toolchains, and syntactic extensions on top of a language that is seen as a fundamentally weak foundation. I mean, I DO understand all of those criticisms. I just don't get how…

I think you're just trolling. But on the off-chance that you may actually be interested in discussion from someone who does a lot of JS, has done a lot of PHP: No, they're different. Firstly: - js is the only choice in browsers. for server stuff, you have an almost infinite choice. - javascript has warts, sure. but if you stick to "the good parts", then it is possible to use in a relatively sane manner. the compile-t…

> node is different, in that bizarre though js may be, if you have to use it in the browser, there is a kind of logic to using it on the server as well.

I don thinkt that makes any sense. Should we also use js to implement the OS for the server? If js is good for server-side use it, if not use something else.

My main issues with php is that I dont trust the language and standard libraries to behave as I expect. There are simply to many strange type conversions, silent errors and strange behaviour going on.

Re: Hack Isn't PHP

#32

Post by jcampbell1 »

nly wrote: post #7

> This is exactly what the PHP world needed: making its already-fast performance many times faster (amplifying one of PHP’s biggest advantages over other common web languages) I think PHPs speed is largely exaggerated here. The interpreter always used to be slow, and before the bytecode cache it was plain awful. Im pretty sure it only ever got away with it because so much of the standard library is thin wrapping. Is…

> Is it really faster than CPython like for like?

It is a mixed bag. There are times where PHP is faster because it is closer to C, where as more python is written in Python. I once ran into a situation where it mattered that PHP's file_exists() is much faster than python's os.path.exists(). I have run into other cases where CPython is much better, such as python's heapq crushes a hand rolled PHP priority queue.

In practice PHP tends to be quite fast, because the standard solutions are pretty unambitious like thin wrappers around CURL, rather than actually implementing HTTP in php.

Re: Hack Isn't PHP

#35

Post by slight »

ceejayoz wrote: post #20
deckiedan wrote: post #18

Earlier quoted context omitted.

I think you're just trolling. But on the off-chance that you may actually be interested in discussion from someone who does a lot of JS, has done a lot of PHP: No, they're different. Firstly: - js is the only choice in browsers. for server stuff, you have an almost infinite choice. - javascript has warts, sure. but if you stick to "the good parts", then it is possible to use in a relatively sane manner. the compile-t…

> if you stick to "the good parts", then it is possible to use in a relatively sane manner Is there any language for which this is not true?

ooh, ooh! Unlambda!

  ```s``s``sii`ki
    `k.*``s``s`ks
   ``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
    `k``s`ksk

Re: Hack Isn't PHP

#36

Post by wycats »

wting wrote: post #13
jimhart3000 wrote: post #10

Earlier quoted context omitted.

> Writing list(, $b) = array(3,4) is not allowed. Instead use $_, i.e.: list($_, $b) = array(3, 4). Not that I think the former is good practice at all, but isn't the latter a kind of weird use of what is a valid variable name?

Using _ as a throwaway variable name is idiomatic in Python, Haskell, and Go. Looks like they're pushing the same idiom in Hack, which I'm ok with.

And Ruby, and Rust. It's close to universal.

Re: Hack Isn't PHP

#37

Post by redwall_hp »

nly wrote: post #7

> This is exactly what the PHP world needed: making its already-fast performance many times faster (amplifying one of PHP’s biggest advantages over other common web languages) I think PHPs speed is largely exaggerated here. The interpreter always used to be slow, and before the bytecode cache it was plain awful. Im pretty sure it only ever got away with it because so much of the standard library is thin wrapping. Is…

I should have stopped reading here:

"Most non-PHP developers judge the entire language by bad code snippets 'written' (mostly copied and pasted) by amateurs for PHP 4"

The old "stop hating on the only language I know! It doesn't have flaws, there are just newbies using it!"

There is plenty wrong with PHP, to this day. When people criticize PHP, they're not usually talking about PHP 4. They're talking about 5.4+. There's some seriously lunacy in the core language. Some of it is there for legacy reasons, and some is brand new.

Re: Hack Isn't PHP

#38

Post by agumonkey »

wting wrote: post #13
jimhart3000 wrote: post #10

Earlier quoted context omitted.

> Writing list(, $b) = array(3,4) is not allowed. Instead use $_, i.e.: list($_, $b) = array(3, 4). Not that I think the former is good practice at all, but isn't the latter a kind of weird use of what is a valid variable name?

Using _ as a throwaway variable name is idiomatic in Python, Haskell, and Go. Looks like they're pushing the same idiom in Hack, which I'm ok with.

AFAIK in Haskell it's not a throwaway variable, a pattern with _ will not create a binding at all. I don't think Python does this, maybe Go.

Re: Hack Isn't PHP

#39

Post by avenger123 »

fish2000 wrote: post #22
wvenable wrote: post #15

Earlier quoted context omitted.

Yes it is. You probably haven't written code in a bad language, but they exist. Most programmers are pretty lucky these days.

q.v. JCL

Job Control Language - Old timers love this. The rigidity of it fits the mainframe philosophy.

Re: Hack Isn't PHP

#40

Post by daleharvey »

StevePerkins wrote: post #30
deckiedan wrote: post #18

Earlier quoted context omitted.

I think you're just trolling. But on the off-chance that you may actually be interested in discussion from someone who does a lot of JS, has done a lot of PHP: No, they're different. Firstly: - js is the only choice in browsers. for server stuff, you have an almost infinite choice. - javascript has warts, sure. but if you stick to "the good parts", then it is possible to use in a relatively sane manner. the compile-t…

EVERY language is "relatively sane" if you only "stick to the good parts". That argument is basically a tautology. As for the logic of using a single language throughout your stack, I would argue two points: [1] It's a myth. If you are a professional software developer, you are going to learn multiple languages... and if you're a GOOD software developer, then this excites you rather than bums you out. So you're using…

I agree that any language is relatively sane when sticking to the good parts, and even that is a stretch with JavaScript.

The code sharing benefits are very real, while backend developers may need to learn a bit about the dom whereas frontend developers may need to learn a bit about sockets / file handles whatever, having a shared language (and libraries) is immensely powerful.

I work on a clone of CouchDB in JavaScript, it also works as an (immature) fully functional server side clone running 90% shared code.

The most used libraries in npm are shared between client and server, it has very real benefits

Post reply on HN