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

Hack: a new programming language for HHVM

code.facebook.com

Post reply on HN
Print view View original

191–200 of 422 posts

Re: Hack: a new programming language for HHVM

#191

Post by Silhouette »

nostrademons wrote: post #180
Silhouette wrote: post #161

Earlier quoted context omitted.

It seems like you're now arguing that PHP isn't a crumbling foundation -- a point that reasonable people could debate -- rather than that building atop crumbling foundations is by far the most successful ways to accomplish anything in computing, which was the claim I challenged. Incidentally, my point about languages like C or operating systems like Windows was not that they are theoretically wonderful under the hood…

I'm curious just what definition you're using for "crumbling foundation". Is it that old software doesn't break on it, in which case PHP/HHVM/Hack isn't a crumbling foundation either - Facebook is built on it, and Facebook is clearly still running. Or is it that maintenance is difficult and programmers will run into all sorts of ugly corner cases and features that are just grafted onto each other? Because those apply…

I didn't have some some specific, technical definition in mind, but if I were to try and pin it down, perhaps in software terms it would be something like "a dependency that is unreliable in the long term".

Clearly this isn't an absolute scale. As our industry evolves and we develop more reliable ways to achieve our goals, something that we regarded as being a relatively stable foundation in the past may no longer be regarded as such in the future when our standards have risen. Moreover, what constitutes "long term" might vary wildly among different projects.

I suppose my basic objection to the original claim (that building atop crumbling foundations is by far the most successful way to accomplish anything in computing) is that significant achievements in computing tend not to happen overnight but rather to develop over time, and the more stable your foundations, the better chance your project has of developing far enough to achieve significant things.

Re: Hack: a new programming language for HHVM

#192

Post by eevee »

m3mnoch wrote: post #139
eevee wrote: post #132

Earlier quoted context omitted.

Which is nonsense, because: 1. I have never seen a framework that didn't go to great lengths to update to new changes quickly in development 2. Which means you lose resources between requests, unless you stuff them into the interpreter/httpd itself. And anyway this is only a problem for PHP , where by default everything runs in the top-level namespace, versus in separate functions. 3. That's a funny way to spin "no c…

blink blink um. have you used java?

nope

Re: Hack: a new programming language for HHVM

#193

Post by United857 »

reikonomusha wrote: post #48

I am baffled as to why you'd build your castle atop a crumbling foundation. I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…

(Disclaimer: FB employee.)

Do you also argue that C++ is built on top of a crumbling foundation, because it's based on C, a ancient language with almost no type-safety?

Re: Hack: a new programming language for HHVM

#194

Post by jwatzman »

curun1r wrote: post #169
jwatzman wrote: post #32

Earlier quoted context omitted.

Engineer working on Hack here. It's complicated. If you use partial mode, which doesn't enforce that every function is fully typed, then it's trivial to break the type system by just using an untyped function. In order to ease conversion, we just assume the programmer knows what they are doing with untyped functions and let anything pass. If all of your code is in strict mode, then we believe the type system to be so…

What was the rationale for being inconsistent in the type notation? Why not be consistent like most languages? For example, in Java you'd write: int add(int x, int y) { ... } And in Go you'd write: func add(x int, y int) int { ... } But it looks like in Hack you'd write: function add(int x, int y): int { ... } Both Java and Go are consistent, either the type comes before or after the name, no matter which context you…

You are reading the documentation right. I wasn't here when the syntax was codified, but my understanding is the following. For parameter types our hands were tied, since PHP actually already has this syntax for object types (unless we wanted to needlessly break compatibility here). We just extended it with primitive types, generics, etc. For return types, we wanted to preserve the greppability of "function add" in large codebases, both for the actual "grep" tool itself as well as for any other tools like ctags that look for strings like this.

Re: Hack: a new programming language for HHVM

#195

Post by hub_ »

jimbrusstar wrote: post #101
reikonomusha wrote: post #48

I am baffled as to why you'd build your castle atop a crumbling foundation. I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…

This seems an unequivocal improvement for Facebook, since they're unwilling to move away from PHP. The better question is why would anyone else choose to build their company on this?

For the same reason there are companies writing software for Windows. Or companies putting Windows on all their workstations.

Re: Hack: a new programming language for HHVM

#196

Post by jwatzman »

lpw25 wrote: post #112
Phlarp wrote: post #80

Earlier quoted context omitted.

Facebook IDE incoming?

I think they mentioned something in the browser using js_of_ocaml at CUFP last year.

The js_of_ocaml bits are actually what are powering our interactive tutorial (http://hacklang.org/tutorial/) -- the tutorial is actually a full build of the typechecker running in your browser :) The source for it is mostly at https://github.com/facebook/hhvm/tree/master/hphp/hack/src/j... minus a little bit of glue.

Re: Hack: a new programming language for HHVM

#197

Post by bluetech »

United857 wrote: post #193
reikonomusha wrote: post #48

I am baffled as to why you'd build your castle atop a crumbling foundation. I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…

(Disclaimer: FB employee.) Do you also argue that C++ is built on top of a crumbling foundation, because it's based on C, a ancient language with almost no type-safety?

Why do you say C has no type safety? Only way around the type system is void, explicit casts and I guess unions.

It admittedly doesn't have a very advanced type system, that's true.

Re: Hack: a new programming language for HHVM

#199

Post by jwatzman »

camus2 wrote: post #111
Touche wrote: post #90

This rubs me the wrong way. > Thus, Hack was born. We believe that it offers the best of both dynamically typed and statically typed languages, and that it will be valuable to projects of all sizes. In which way does it offer the benefits of dynamic typing? The entire point seems to be to abandon dynamic typing, which is fine, but not what that sentence says. I'm guessing, for example, you can't really do meta-progra…

AFAIK large PHP libraries(Doctrine/Symfony) generate PHP code (from config files for instance) that is then required and executed. You cant be more meta than that. I dont know if you can do that with Hack, but that's definetly a big PHP pattern.

It depends on what you mean by "with Hack". You cannot do this in Hack code -- we disallow the dynamic features of the language you need to do this; they are impossible to statically typecheck and verify. However, Hack code iteroperates seamlessly with PHP code, so there's nothing stopping you from having some PHP files in your codebase that do anything that standard PHP can do.

Re: Hack: a new programming language for HHVM

#200

Post by julienv »

fzltrp wrote: post #130
bos wrote: post #3

I'm the manager of the team that developed Hack, and I'm sitting here with some of the language designers. Happy to answer your questions.

Great work! A question about the type inference mechanism: in PHP, while it is possible to define object interfaces which classes may be defined against, by the dynamic nature of the language, functions don't necessarily need that interface specification to accept an object conforming to it, explicitely or implicitely. OCaml provides something "similar" with its object system, but much more powerful with static infer…

There seem to be 2 questions here: 1) Is Hack type inference total? Answer no: you must annotate parameters and return types.

It would be pretty much impossible to implement total type-inference without loosing separate compilation in Hack. PHP projects are not organized around a module system, which means that you have "spaghetti" dependencies, and even better, cyclic dependencies all over the place.

So trying to implement total type-inference would be a bad idea, you would not be able to separate the code in independent entities and the checker would not scale.

2) Does Hack support structural sub-typing? Answer: No, but not for obvious reasons.

Fun fact, the first version of the type-checker was implementing structural sub-typing. And it was not scaling, for subtle reasons.

Hack allows covariant return types, so if we implemented structural sub-typing we would have to "dive" into the return types of each method to see if they are compatible. But in turn, these objects could have covariant return types etc ... The process of checking that was too inefficient. Caching is a bad idea (or at least a non trivial idea to implement), because of constraints and type-variables.

Since disallowing covariant return types was not an option (it was crucial to make a lot of code work), we had to kill structural sub-typing.

I hope this answers your question. As a big OCaml fan myself, I like the features you just mentioned (Well, Hack is written in OCaml), but they really didn't seem to be a good fit due to the nature of the language and the kind of checking speed we were shooting for.

Post reply on HN