Live data from Hacker News

Hack: a new programming language for HHVM

code.facebook.com

161–170 of 422 posts

Re: Hack: a new programming language for HHVM

#161

Earlier quoted context omitted.

Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? I can't imagine where that sort of conclusion comes from. Building on a crumbling foundation seems to be just about the most proven, reliable way to ensure your software project won't survive more than a short time without needing serious effort just to maintain it an…

PHP is a "crumbling foundation" in exactly the same way DOS, Windows, COBOL, and C and C++ were, are, "crumbling foundations". I don't see how you are disagreeing with me. You are proving the point. You aren't actually going to claim that Windows was well-conceived and theoretically well-founded, are you? Windows has been a never ending refinement on exceptionally shaky ground.

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, merely that they provided a reliable foundation. C has been standardised for a long time and is widely portable. Code that was designed for early incarnations of Windows will often run with little modification even on today's systems because the essential underlying models and APIs have been diligently preserved over the years even as many other changes were going on around them.

Re: Hack: a new programming language for HHVM

#162

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…

Something I didn't really learn in school, that I only picked up much later in my career, is that when applicable, applications should be built on top of mathematical models. A very contrived example would be.. would you build an ad rotator by keeping counts of all banners served and picking the next banner based on those counts and your weighting rules, or would you build the rotator on a foundation of statistics an…

I built an ad engine base on probability. But I am not sure which way is better.

Re: Hack: a new programming language for HHVM

#163
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.

With Async functions I'm not sure if the documentation is lacking or I'm just slightly thick, I believe the later.

(I'm not a php developer so excuse my ignorance)

It seems you only have 1 method 'await', to check if the async function has completed its job (it self, if I'm understanding is a blocking operation in which ever thread/worker its called).

So is there a way to run something more similar to

      $i = 1;
      while(doingSomeThing)
      {
             $b = "";
             if(completed gen_foo())
             {
                    $b += await gen_foo();
                    do_critical_task($b);
             }
             else
             {
                    do_something(do_item[i]);
             }
       $i++; 
       }
Because as I see it now, what ever I run asynchronously I.E.:

       gen_foo(get_user_data); //async
       $x = do_something_for_a_while(); //do something while gen foo processes
       do_new_thing($x, await gen_foo()); //do something with rendezvous result
I'm forced to time out my async calls so that they'll rendezvous in the same place won't I?

Again if I'm completely off the mark please let me know.

Re: Hack: a new programming language for HHVM

#165
post #64

It seems like a strange monster with PHP body and C++ head or the other way around you choose

Yes, pieces of Hack will feel similar to other languages.

bos said in another thread: "Yep, we're happy to be inspired by good ideas when they're obviously the right path to walk."

Re: Hack: a new programming language for HHVM

#166

It looks promising, I highly dislike writing PHP and this seems like it might ease the pain, but they could've gotten rid of the damn dollar sign in front of variables, how ugly is this? "return ($y) ==> { return $y + 1; }"

Engineer working on Hack here.

You can actually write you example a bit more concisely in Hack: "$y ==> $y + 1".

Re: Hack: a new programming language for HHVM

#167
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…

The benefits of dynamic typing come because you are not forced to convert all your code to the statically typed version. You can still keep some parts synamically typed if you want

Re: Hack: a new programming language for HHVM

#168
post #138
post #85

Earlier quoted context omitted.

> I am baffled as to why you'd build your castle atop a crumbling foundation. Because perfect is not the enemy of the good? Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? Unless you have some example of perfect, now dominant, technologies that have been created ex nihilo that I'm missing? I mean we (facebook) are…

> Just so we are clear, you ask why Facebook didn't rewrite 10,000 human-years of code into a mythical unnamed "proper" ... You don't need to rewrite anything (at least, not all at once.) Personally, I'd have expected you to make something akin to CoffeeScript or ClojureScript that targets PHP, and can "link with" your existing PHP modules (or rather, with their HHVM bytecode representations.) Then treat the PHP code…

> Personally, I'd have expected you to make something akin to CoffeeScript or ClojureScript that targets PHP, and can "link with" your existing PHP modules.

We took a similar approach to what you described. Then we called it Hack.

This is what we mean by seamless inter-operation: the HHVM runtime understands both syntaxes and runs both <?php and <?hh code in the same process. Whether Hack integrates into the runtime at the parsing (current) or bytecode (future?) layer is an implementation detail.

Re: Hack: a new programming language for HHVM

#169
post #15

Earlier quoted context omitted.

whats the state of the type system like? Here[1] it suggests that it may have bugs, is this a 'covering backside' thing or is it currently unsound? [1] - http://hacklang.org/manual/en/hack.annotations.summary.php

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're dealing with, be it return type or argument type. Hack seems to mix the two styles, which seems like it would make code harder to read as things get more complex, like when functions accept other functions as arguments.

Am I reading the documentation right? And, if so, can you shed any light on the decision making process that went into this decision?

Re: Hack: a new programming language for HHVM

#170

Earlier quoted context omitted.

Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? I can't imagine where that sort of conclusion comes from. Building on a crumbling foundation seems to be just about the most proven, reliable way to ensure your software project won't survive more than a short time without needing serious effort just to maintain it an…

PHP is a "crumbling foundation" in exactly the same way DOS, Windows, COBOL, and C and C++ were, are, "crumbling foundations". I don't see how you are disagreeing with me. You are proving the point. You aren't actually going to claim that Windows was well-conceived and theoretically well-founded, are you? Windows has been a never ending refinement on exceptionally shaky ground.

I'm appalled and little bit insulted that you group PHP in the same group with COBOL, C and C++ in terms of their foundation. COBOL and C were designed by some of the greatest pioneers of the field, and indeed PHP is built on C.
Post reply on HN