Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

alokmenghrajani (2602135) writes with news of Facebook's new Open Source language, Hack. Quoting: "Today we're releasing Hack, a programming language we developed for HHVM that interoperates seamlessly with PHP. Hack reconciles the fast development cycle of PHP with the discipline provided by static typing, while adding many features commonly found in other modern programming languages. ... Traditionally, dynamically typed languages allow for rapid development but sacrifice the ability to catch errors early and introspect code quickly, particularly on larger codebases. Conversely, statically typed languages provide more of a safety net, but often at the cost of quick iteration. We believed there had to be a sweet spot. ... Hack has deep roots in PHP. In fact, most PHP files are already valid Hack files. ... Our principal addition is static typing. We have developed a system to annotate function signatures and class members with type information; our type checking algorithm infers the rest. Type checking is incremental, such that even within a single file some code can be converted to Hack while the rest remains dynamically typed. ... If a function parameter or class member does not have an explicit type annotation, the type checker considers its type to be dynamic, and it does not check the type of that value."
In addition to static typing, they've introduced proper closures that capture the lexical environment, generics, collections, and array shapes. The Hack website has more details. There's a fairly complete language manual, tools to infer types in PHP source and annotate the code, and source available under the PHP license.

Dynamic typing frees your mind to think about the problem at hand and the best solution to that problem, rapidly changing approach and methods as you learn from experience gained. I get sick of spending half my time dicking around with static types, casts, etc and spinning my wheels chasing down type errors when I could be progressing rapidly towards a solution. Unless I'm writing kernel code for a drive by wire system or something similarly life-and-death, I'll take dynamic typing any day and be done twi

I get sick of spending half my time dicking around with static types, casts, etc and spinning my wheels chasing down type errors

If you spend half, or any appreciable part of your programming time dealing with static typing issues, then you're doing something seriously wrong. Occasionally the compiler will be a pain in the ass about it, but most of the time static typing should require nary a thought. If it's otherwise, you're not thinking about types clearly. The static typing is there to catch you when you screw up. It also serves as useful documentation for the next poor schmuck that has to look at your code, and for good measure

So do you rely on implicit or automagical type conversions? That doesn't do much for error checking. No, I don't do web programming, but I've worked on code that had to do a lot of string to whatever conversions. The biggest pain, but one of the most important things, is detecting errors in the string format. You need an explicit function to do that right, and a way to handle the errors. Once you have the explicit function, what's so hard about declaring that it returns an object of class ObiWan?

Dynamic typing frees your mind to think about the problem at hand and the best solution to that problem

Quite the contrary. It frees your mind to think about the problem incorrectly, then requires your mind to churn through many incorrect ideas before finally settling on the correct one. Meanwhile, static typing deals with a large chunk of correctness for you, and gets you to the correct solution faster by pointing out the errors before you hit them at runtime.

I get sick of spending half my time dicking around with static types, casts, etc

If you're casting, you're not thinking about the types correctly yet. Learn to code a bit better.

Otherwise, you'd have to run your program, and discover that type error at runtime.

Don't be absurd. Type problems don't show up during testing - they show up 3 weeks after the code has been released, and then only in situations that are practically impossible to reproduce. That makes debugging more interesting. Any idiot can find type problems when the compiler does it for you.

Usually the compiler will scream "Hey fuckwad, your integer array ain't a string! Error on line 205", and then you dutifully go correct the error. Much better than a dynamic language that happily takes your screwup seriously and you have to follow a debugger chain through half a dozen nested functions to find where you buggered up.

when I work with dynamically typed languages I tend to spend similar amounts of times if not more figuring out what really is and is not supported with this dynamic object in front me

Much worse than writing dynamically typed code is reading it. If I write function foo in a dynamically typed language, I know it's supposed to return an integer. If I'm reading somebody else's code, I often winding up guessing that an integer makes sense. Of course it may return a float or a string on odd Tuesdays when the moon is full. Much nicer for it to explicitly say it returns an integer, and have the compiler check that that's the truth.

Yeah, with static typing, there's a whole class of errors that simply can't happen. Any time you lose from having to explicitly declare variable types, or casting variables to the correct time is easily saved by the fact that you don't have to write as many tests. Unless you aren't writing any tests, in which case, you have other problems.

With a properly set up type system, you express one type as the non-null pointer. You then express a second type - the maybe type, which describes something that is maybe something else. Now you use the Maybe Pointer as the result of allocation. Now in order to use the pointer, you need to get it out of the Maybe or the type system will complain, which enforces that you actually check for null before dereferenecing. It proves that your program will never de

People are going to explain this at dinner parties. People who kind of understand that programming is more than being good at operating a computer as an end user but don't really know the difference between sysadmin, devops, programmer, business analyst, and DBA let alone what those roles really do are going to ask questions. Those questions will be things like "what kind of programming?", "what technologies do you use?", and "what are you working on right now?" The answer will be something about putting together a quick Hack program to change values in a database, and then it gets awkward.

Plus, did they consider at all how easily this will get confused with Haxe?

It's actually very clever marketing. Now everybody that searches "facebook hack" will get this as the first result. They get lots of hits for their new language and obfuscate any articles teaching people how to exploit FB accounts. Win-win.

It's actually very clever marketing. Now everybody that searches "facebook hack" will get this as the first result. They get lots of hits for their new language and obfuscate any articles teaching people how to exploit FB accounts. Win-win.

Uh, people exploiting Facebook?

Ironically, you have that completely backwards.

Don't feel bad for making that common mistake. The billion other users did too.

Okay, stupid name aside, this is awesome. I've never had a single good thing to say about Facebook or Mr. Zuckerberg, but this could totally change that. Lots of devs disparage PHP, but they're all idiots -- PHP is heavily used because it's heavily useful. I haven't used HACK yet, but if it's not a buggy piece of junk might truly be great. I've yet to find a language that lets me go dynamic when I'm prototyping but gradually type when I see fit. So...Sweet!

or they haven't looked closely at the newest changes to the language in the last two years.Or they are talking more about the "PHP community", thousands of "scripters" who use PHP because it's easy to build things in PHP, in the same way that it's easy to build things with Legos.

I helped write the PHP certification test, which suggests I know a little something about PHP. My PHP code is used by many large universities. I could go on, but suffice to s

This sounds a bit like layering design by contract on top of a typically dynamically typed language rather than being a strictly statically typed language. It's an interesting approach and would seem to achieve their goals of faster but more robust development.

The single biggest problem with PHP is the tendency for old code and old programmers to keep their bad habits around when moving to new projects. PHP lacked vital modern features (like static typing and namespaces) for so long, and it's evolved so many workarounds (like magic quotes), that programmers have learned the wrong way to accomplish basic tasks. Now they have a new language, supporting the right way to do these things... but the old and broken ways still work. Sure, there will be a few programmers that will use the new way and be thrilled about the good technique, but then time crunches will set in, and code reviews will be rushed (or nonexistent), and those old ways will creep in, bringing the bugs with them.

Backwards-compatibility with a broken language is a great way to improve a new language's adoption, and a terrible way to build a new language's reputation.

That's deprecated too, but I'd bet there's still folks out there clinging desperately to it and using it daily in production code.

Also, you should consider that I don't keep track of PHP's changes, because they'd have to change most of the language for it to be salvageable. I'm not trolling with outdated FUD; I'm arguing with one almost-outdated fact. It's almost outdat

Parameterized statements are fine if the number and order of parameters in a particular query won't change from one execution to the next. But what's the alternative to calling the database connection's escape_string method if an application needs to include a variable number of values in a query? An example is the list on the right side of SQL operator IN. What I did [pineight.com] back when I still used MySQLi was make a single function that turns an array into a correctly escaped and parenthesized IN list using the dat

That's fine so long as all users of your application are on hosts that offer PHP 5.4.0 or later. Shared hosts tend to stay on old PHP, possibly with backported security fixes, so as not to expose their customers to breaking changes. They also tend to limit the extent to which customers can configure the web server, PHP, and database. I had to wait for my annual renewal in order to move my personal web site from another host to WebFaction in order to get halfway recent PHP.

Every few months someone announces a new fad language despite them rarely bringing anything new to the table, or the new things they do bring not being significant enough to warrant switching from some other well-established one.

I'm actually happy with this one, because it serves an easier to justify purpose: migrating your existing PHP codebase and developers to something that is immediately better and familiar.

Microsoft added static typing to Javascript (with Typescript). Now Facebook is adding static typing to PHP. After a few years of dynamic languages being in vogue, is the pendulum swinging back to statically typed languages?

For example, if floating point variables x and x were be classed as 'Lengths', and you stated "a = x * y;" a would have to be classed as an Area.

If you then stated "a *= 2;" a would still be an area (of twice the size), but "v = a * x;" would return a Volume class, and "a = a * x;" would be a compile time error (trying to assign a Volume result to an Area class)

Not a bad idea. If your classes have no virtual methods and they don't allow mixins or other crazy runtime dynamic shenanigans, then in theory the compiler can optimize them down to un-boxed numbers. I wonder how man OO languages are very good at that though. The hard part might be the base class. If you don't even have un-boxed numbers and the base class has virtual methods... you're kind of stuck with something less than optimal.

I've contemplated a language/library with extra strict typing for doing real-world calculations. For example, if floating point variables x and x were be classed as 'Lengths', and you stated "a = x * y;" a would have to be classed as an Area.

You want C++11. You can infer the Kg/m/s powers etc using a small amount of template hackery. The thing that C++11 adds is user defined literals, so you could type:

My interpretation is that they've put a lot of work turning PHP into Java or C. Why go through all this effort when they could simply used one of the C-like strongly typed languages is beyond me. All that effort could have been put into creating a PHP-to-Java converter or something along those lines.

But hey, it's Mark Zuckerberg's bazillion dollars. If he wants to tape testicles on a eunuch, be my guest.

Hack is more than turning PHP into Java or C. Java's type system is way different than C's (there are no objects in C). Hack's is different than Java's because it uses a type inference system. It also type checks incrementally, which allows the quick edit/save/reload cycles web developers are used to.

Java has had quick edit/reload cycles since there was hot code replacement. If you see Java developers recompiling / restarting their entire project every time they make a change, then unfortunately they just don't care enough and/or are incompetent.

For projects that I'm assigned to, the first thing I look at is making sure the turnover time is below 10 seconds.. if it isn't, I fiddle with it until it is. And yes, that works for Facebook sized websites as well.

That's not what Object programming considers an object. It would be more like:"A struct and all the functions that use it as the first argument" depending on the language. Some languages would have it be a pointer to the above. One of the critical aspects of an object is that is has a local scope for each instance. In C this either means you are holding it on the stack, or you've done a malloc.

That said, you can definitely do object programming in C. Existence proof is offered by valac -C which takes Vala code and emits a C equivalent. (It uses the GObject protocol to do so.) Mind you, the code that it emits is nearly unreadable, but it *is* object programming in C.

Why go through all this effort when they could simply used one of the C-like strongly typed languages is beyond me.

Because they already have a huge PHP codebase. That said, Twitter moved from Ruby to Scala for their back-end [theregister.co.uk]; it seems it can be done. I suspect Facebook have more of a lots-of-programmers problem: they all know PHP, and they might not all know, say, Scala.

to creating a PHP-to-Java converter or something along those lines.

You mean take PHP source and translate it into readable, maintainable Java source? That's all but impossible. They're very different languages, and source-to-source translators tend to produce pretty unreadable code when faced with that kind of task. A h

For pragmatic-minded people, PHP is an extremely productive language to work in. No compiling, or waiting for compiling, no object files to mess with or get out of sync, and still relatively good speed. It really removes a lot of inconvenience between the programmer writing code and testing it. Despite what the detractors say, I've always found it a joy to work in (and I have worked in many languages).

The down-side has always been that the language also had many sloppy characteristics. Modern PHP has cleaned up a lot of the language design errors, and static typing is extremely useful for reducing quantity of bugs (I know this as I developed a PHP fork that enforces this and it's saved me many many times over the years). HHVM adds much more speed, so that really complex modern social webapps are really needing. There are still many small inconsistencies in the language, but it's not a big deal given the other advantages.

PHP is productive in that it can work as a fast prototyping language. Even I recognize that, and in fact use it as such.

Where it falls down is that it doesn't enforce the kind of discipline that better languages do. It is well and truly the BASIC of the 21st century.

That's not to say you cannot write good code in PHP. I do strive when I have to work in PHP (which is more than I would like) to write well-formed code, use newer language structures and so forth. But still, and maybe it's because I like the crutch, I just feel better coding in statically typed languages, and to be pretty blunt, if PHP is evolving into that kind of language, there are far better languages out there.

"For pragmatic-minded people, PHP is an extremely productive language to work in. No compiling, or waiting for compiling, no object files to mess with or get out of sync, and still relatively good speed. "

You mean, like any other interpreted languages you could choose?

"The down-side has always been that the language also had many sloppy characteristics."

You mean, like those avoided by any other interpreted languages you could choose?

Ah, it seems I started a religious language war simply by sticking up for the tool I (have to) use;-). I've not claimed PHP is the best language, only it is a comfortable language to me and many others. I just do not feel the pain some developer's always claim to feel, the inconsistencies just don't cause ongoing real world problems for me. I do not lose productivity on a day-to-day basis, they do not cause additional bugs (well, dynamic typing could - and a small number of other things could if you don't have a framework / know the issues), they do not make the code unreadable, and I do not have a problem hiring or training competent developers in the language. Whatever problems there are are easily resolved, and the smallest problem I have as a professional. A PHP developer not aware of the few issues to avoid, would also not have the basic field knowledge to avoid a myriad of other pitfalls that affect all programming languages. I know so many people will read this and think "but there are issues, and you can't excuse that" - I'm not - but I also firmly believe going through your professional career with so much anality for the small niggles doesn't help anybody, and that instead of whinging, people should put their energy into something more productive and positive, like concentrating on client ROI (and no, the 5 minutes you took looking up an inconsistently named function the other day doesn't make an identifiable difference to it), or perhaps, putting in RFCs for cleaning up the issues for PHP6.

The reason I develop in PHP is because I write consumer software to deploy on web hosts, and I don't chose the web hosts, and PHP is the overwhelming 'standard'. Probably the world would be better if Python replaced PHP, but bitching about the tools people use with arguments that the users of said tools simply cannot relate to, just seems ridiculous, and annoying because it just undermines the good work some seriously talented/hardworking/worthy people are doing. There is absolutely no reason PHP cannot continue to evolve, step by step, without forcing the entire hosting industry to adapt to something else (which is never going to happen).

I just ported a project from ASP.net to PHP, and my God the problems I saw in that language. Whenever I look at Ruby code, I just see the most inelegant syntax - it just looks like it was deliberately designed to combine being cryptic in some places, with pulling in English words where self-describing layout would be better. And then there are a host of academic languages which have elegant concepts, but poor libraries, or just are too over-complex for real world use.

For what it's worth, I think the world would be better off if Javascript was replaced too (I get annoyed by that much more than PHP actually, because some basic programming constructs are just hacks, and it is literally impossible to write elegant looking code).

To be fair to Facebook, no other languages had those advantages in 2002-2003. Assuming you didn't want to use F/CGI, plugins for Apache or the equivalent, your server-side scripting options were JSP, Asp.NET and PHP.

PHP was a reasonable choice under the circumstances, but they've now reached the limit of what it can do. It's good to see that they're moving to an entirely new and better language which just happens to have a similar syntax. If I was a Facebook engineer, I could live with that; syntax matters, but it doesn't matter as much as semantics and pragmatics.

To be fair to Facebook, no other languages had those advantages in 2002-2003. Assuming you didn't want to use F/CGI, plugins for Apache or the equivalent, your server-side scripting options were JSP, Asp.NET and PHP.

Wow, they couldn't port a simple web app into a mature language in 10 years. You have to wonder what kind of programmers they hire.

Php (Personal Home Pages) is already something it was never intended to be. It's the "hey thats a nice feature, let me add a crappy implementation of it" language. If you mean "turn PHP into something never inteded to be" as turning it into something not absolutely horrible to work with then OK. Anything they do is going to be better than PHP. You would have to try really hard to make it worse.

People always moan about how horrible PHP is, and I always assume that the people moaning are trying to learn the language without having a basis in C because they have come straight from Ruby or some other perfectly designed load of academic twaddle nobody uses.

The reality is that PHP is like C, an amazingly flexible and well used tool. Yes, it has tons of quirks due to its slow evolution where they maintain backwards compatibility, but that is it's strength in the real world since nobody wants to rewrite

that's great.. but the reason Scala is so sweet is that it does type inference. This means all your code is purposely typed even though you don't have to type all the tries (AC doesn't have to apologize for puns). This is going to be a nightmare where your last five dynamic functions his the bug that kills you.

It's so sad that the fact that Mark got extremely lucky means that all this excellent computer science is wasted on a cesspool like PHP.

Hack does type inference. It doesn't do let-polymorphism because that plus subtyping is formally undecidable. But you only have to declare the types of functions, not every variable inside those functions.

Many years ago I was a fierce opponent of static typing and loved the power of Obj-C and Python (was a NeXT/Mac head.) C++ and Java were crap (especially since Java didn't have type variables at the time.) Then I tried Haskell and my mind was duly blown. Now I'm a huge proponent of static typing, even if I still can't stand Java and avoid C++ unless necessary. IMHO Scala is the current sweet spot for statically typed general purpose programming language.

I wish there was just some voluntary static typing in python. By this I don't mean run time voluntary type checking. that makes it slower. No I mean a pre-run time filter that optimizes the.pyc to the extent it can.

"This saw sucks. I can't drive a nail with it. And what's with this useless hammer? Look at the jagged splintery bits I get when I try to cut wood with it!"

I don't get why there's a holy war between static and dynamic typing in the first place. Different tools for different problems. I don't trust any software engineer very far when they say things like "$LANGUAGE [sucks|rules] because it's [statically|dynamically] typed."

Haskell's NIH version of SQL is tedious. Why didn't they just implement SQL?

I haven't tried SQL, but in general Haskell's libraries are one of its weaknesses.

Also, closures seem to me to violate the premise of static variables and fixed variable scoping. When you introduce closures into a language they are bound to cause all the same problems as global variables.

I don't agree. A closure should produce a new pure function (some languages allow otherwise, but not Haskell). With functions as first class objects, you can just pass and return them like data. There is nothing about that that suggests the evils of globals.

As a Java EE developer I'd advocate the benefits of proper application servers/infrastructure but ASP/Java are slow to release languages. You need infrastructure and planning while PHP is a great language for systems that don't have huge reliance requirements and need the project done yesterday. (and even then obviously Facebook has managed to make it very reliable).

Additionally ASP.NET (with C# as you didn't specify) is statically typed. Even the "var" type is

In any sane programming language, you can access the bytes directly as an indexed array.

You can do that in C; but you shouldn't. There are too many things you don't know:

1. Debug or release? That could change the structure layout.

2. Structure padding.

3. Byte-order.

IIRC, they call such a cast "type punning". They got away with it in network stacks on BSD; but that was a long time ago, *and* they no doubt had knowledge of all the compiler switches and CPU architecture.

Why do we need to "pack" and "unpack" the data? In any sane programming language, you can access the bytes directly as an indexed array.

Because it's a simple way to control the endianness and low level layout of binary data. Few "sane" programming languages provide that level of control with direct memory accesses, Ada being one exception and even that requires some extra incantations to make work.