They didn't make it very clear, but I think the embedded SQL idea is meant to be for things like querying against collections, similar to LINQ[1]. Even it's meant for databases, it's still up to you where in the app you put it.
That being said, my initial reaction is to wonder why, when designing a new language, one would model after PHP of all things.
Yeah I'm also not a fan of linq. Or at least not in my PHP.
I think something like underscore.js[1] would be much more in the style of PHP - I always thought PHP and JS were similary in their wackiness - and I would much prefer it to LINQ.
As far as modeling after PHP, there are things I'd leave/take, but really the biggest issue is the standard library.
Here's a contrived example to demonstrate the value of sigils:
/* in version x of SFL (Sigil-Free Language) */
school = get_school("Saint Fred's School For Girls");
class = get_class(school, "Agricultural Studies", 12);
yield = get_agricultural_yield(class, "Turnips", 2011);
printf("The Year 12 Ag Studies class produced %d turnips in 2011", yield);
Now we try upgrading to version x+1 of SFL, which adds object-orientation and concurrency (it was a BIG upgrade!). Now three of the lines in that four-line program contain errors, because "class" and "yield" are no longer valid variable names, having been turned into keywords.
In a language with sigils, that's no problem. It also makes it easier (therefore faster) for syntax highlighting to spot where variables are used, without needing a full dictionary and an exact version number - that makes a difference for me as an Emacs user especially.
etfb is on the right path, but for me it just feels right. I guess that's just a personal preference, but the dollar sign is a visual indicator that a particular string is a variable, and not a function call.
For me, it makes a big difference in languages like ruby where you could either be calling a method, a monkey-patched method_missing callable, or a property in some scope.
Well, in PHP you already have a mandatory '()' at the end of function call - so it's pretty hard to confuse the two.
Additionally if your language has first class functions, it would feel kind of strange if names of some functions started with $ and others without it.
Good point. If variables can be functions and functions can be represented by variables, variable naming rules would to apply to functions both declared and assigned. Which is to say all functions. The $sigil would have to melt away or be everywhere.
Really? It's cleaner to have queries represented as strings than as a language-integrated syntax that can throw errors at compile time? To each their own, but if I had to guess, I'd say you've got a minority opinion there.
I doubt it's a minority opinion, at the very least amongst PHP devs. Having it as a string allows me to pass it to a logging function, or output it in a debug console, or send it to a query pre-processor that adds the right database prefix for the current app, etc.
As encoderer said, you can definitely do that in Linq. The query operators basically just map to methods, which are overridden by the different providers... The SQL ones basically create SQL statements for you behind the scenes (as log gable strings).
I thought it was all kind of weird and wrong at first too but now it's probably my favorite c# feature next to the (very much related) lambda expressions, especially for non-SQL collection queries. Of course this doesn't mean PHP needs integrated queries or anything, but it is a very nice feature to have if done right. XML/json literals, on the other hand, do feel kind of wrong to me though (although I bet they are handy still, as many vb.net devs will probably attest to).
Native JSON is a nice step, but for the most part I would have to agree with the other commenters.
Especially embedding SQL as a literal as seems more convoluted than clarifying.
I think it might be elegant in small doses - just look at C#'s LINQ. Also, it's a nice strategy to lure newbies away from string concatenation and give security for free...
Sometimes on rainy nights when I've had a few too many glasses of wine, I dream of doing a PHP "reboot": something with syntax and features like C#, which I personally love, but without the sometimes deceptive magic that goes on behind the scenes of stuff on the .NET stack. Just output HTML to the browser, no compilation required, arrays like PHP, and sane and useful built-in libraries. FOSS.
Sometimes I even think it would be a good idea to half-ass it and just create a "wrapper" type library to map built-in PHP functions to namespaced and standardized (naming, parameter order, etc.) functions.
Then I usually wake up in the morning with a bad hangover and a deep sense of sadness.
I just wonder: how are you supposed to escape braces in embedded JavaScript? If the language 'intelligently' finds braces inside <script> tags, then I'd recommend everyone to run as fast as possible in the opposite direction.
What exactly is the philosophy of PHP? You should write a bit about it on the project page.
Right now it looks like a completely different language, and you might as well just give it an original name. I'm having a bit of a hard time seeing the connection to PHP here.
When will people realize that the main reason PHP was/is so successful has nothing to do with the language? PHP got huge because it's free and super easy to deploy on commodity-level hosting. Ubiquity breeds popularity.
Basing a reboot on the JVM makes little sense in this context.
That said, you lost me at "less ';' like in javascript".
IMO you are only partially right and some of PHP's success does have to do with the language and not just availability.
As horrible as PHP is, it is really easy to sit down with PHP and a tutorial or a book and start banging out code that gives you instant results. PHP is like the MS Basic 2.0 of the web era -- people who aren't really programmers (yet?) can sit down with it and GTD right away -- their code may be ugly but they can see it working as they go. They don't have to learn what a 'WAR' directory is and how it is structured, they don't have to mess around with xml configurations, etc. The ubiquity helps, certainly, but IMO the reason it got ubiquitous is how easy it is to go from nothing to "hello web world".
I think a project that maintains this instant GTD environment but improves the language is actually quite a good idea, though I also think cutting ties with PHP by giving it a new name makes more sense than calling it phpreboot and once you involve Java it seems less likely PHP's context-free easy start-up will be maintained.
That's exactly right. I learned to code from a PHP book a decade ago, and now I am using the excellent OOP Symfony2 PHP Framework. The full spectrum of options are already available with PHP, the language and its frameworks lack nothing.
It lacks a coherent design philosophy; it's a collection of hacks; a house of cards with no style. It's full of idiosyncrasies that must be memorized because they make no logical sense. Put simply, it completely lacks taste.
Right, and under the category of easily:
What languages do you already know,
What languages are you already actually comfortable using for a large scale project, and
What is the production server running.
If the answer to all of the above is PHP, then you're going to get projects done faster there than you would in Python or Ruby.
As horrible as PHP is, it is really easy to sit down with PHP and a tutorial or a book and start banging out code that gives you instant results...
You could say the same thing about ASP, or even ColdFusion.
I'd argue that those instant results had more to do with the higher availability of PHP on cheap web hosts, than the accessibility of the language itself.
Being able to do something like install Apache with modphp in one go and then just put a file into the correct directory and have it execute code is without a doubt the most low barrier way to get started. Other languages are catching up though, but taking a different route (e.g. hosted platforms like Heroku).
Basing this on the JVM may afford some benefits, but widespread adoption will not be one of them. I'm a big Groovy fan, and love Grails, but it's never going to challenge PHP in uptake. I get a lot of JVM benefits by using Grails, but I still do a lot of PHP too, and each have their place. I suspect others would chime in with their own non-PHP loves (ruby, c#, python, etc) but PHP's massive adoption has a lot more to do with availability than syntax.
The people that don't like PHP's syntax already use other tools when they can, and when they can't, because they need to use PHP, it's likely going to be because they're using some existing PHP library or platform already (wordpress, drupal, etc).
I'm all for people experimenting and trying to make things better, but you're probably better off just making a new language than trying to make something that's sort of like php, but different enough that existing code libraries won't work with it.
One extra comment different from my last - easier Android app development could make this a very interesting project. That's assuming this as a JVM language will work on Android (groovy doesn't right now because of too much AST stuff, fwict).
Would a coffeescript-like language that generates php be something of interest to people? Improving the syntax whilst maintaining the ability to just drop onto an apache server.
Probably to some people, sure. For totally 100% from scratch projects, it might be nice - may be harder to deal with existing code bases that you want to extend or integrate with, no?
It would be really cool. In fact, I was thinking about that right now.
Just convert and bingo, instantly deployable on 100% of php hosts. For local development, a script with --watch a la sass, or maybe a single index.php for converting things on the fly...
Yes, that would be something huge (or maybe I'm thinking that because I have this idea for a long time and really wish someone would do this).
Obviously, the quality of the output php code would matter a lot. Actually, by quality I mean mostly the performance.
I've started something like that a year ago. It's called purplescript( https://github.com/martinrusev/purplescript ) and it's a ruby like language written in Python ( with PLY ) and it compiles directly to PHP, so there is no need to rewrite PHP functions - they just work.
My PHP reboot is simple: drop it for more versatile interpreted languages like Ruby & Python, and their respective web frameworks. Loving it, personally.
Why, when "rebooting" PHP, do you still keep the inane non-object arrays? Why not either/both create a syntax for manipulating arrays, or promote arrays to objects with their own methods.
When I see special functions which exist to do basic array-as-list operations, like his `add()` function, my eyes roll. Then I see arbitrary, inconsistent use of the dollar sign to indicate variables and they start to bleed -- you either have a dollar sign or not, but pick one and make it work.
When the language designer adds features at whim, without considering whether or not his implementation is keeping consistency or breaking it, well that's how you get a language like PHP in the first place!
what might make sense is to only implement the SPL stuff, and force all array access to be objects implementing the SPL interfaces. it would hurt 'ease of use' compatibility, but would enforce as a standard something that's already defined in PHP.
A better approach might be to go the CoffeeScript way or better still, contribute to php itself. Sure it might take longer but languages take years to catch on...
Native parsing of markup and SQL looks like a neat idea (reminds me of Facebook's XHP plus LINQ) but I'm concerned about using the JVM. Does this use a .NET style multithreading model instead of using one process per request? If not, I can't see the benefit of using a JVM given its best features (GC and JIT) would be rendered not only useless, but a bit of a drag.
My personal PHP wishlist is:
* Better interfaces for the core libraries. Ideally replacing them all with namespaced and object-oriented ones with none of this needle-hackstack mixup
* A standard autoloader
* Removing the concept of 'PHP errors' and replacing them all with exceptions
Interesting, this is by Rémi Forax who is involved in the Asm Java bytecode manipulation library[1] as well as hacking on all kinds of other Java related stuff.
He's got a blog post here with some initial performance tests:
Looks really fast when using type annotation (edit: faster than Java?!). Interestingly he is using the upcoming -hsx Hotspot server flag which makes a big difference in speed.
PHP has only one feature going for it: it already exists. As soon as you introduce a new programming language, you lose what PHP has to offer. Another success is the lack of a library culture -- just copy-and-paste code into your app, and you never have to worry about installing dependencies on your shared host.
If you want a better version of PHP, try Perl / Python / Ruby. If you want a language that can check your code for safety at compile-time, use Haskell. But if you invent your own language, it will have three problem: nobody will know how to use it, it won't be installed on any three-dollars-a-month shared host, and it won't have any libraries.
If you can't solve the "I want to use it for $3 a month" problem, your programming language is a failure compared to PHP. If you can afford more than $3 a month for hosting, then you're not using PHP anyway. Most people learn to program because they want to share something with their friends. They choose PHP because it lets them do that, and they don't have the experience to know that They Are Doing It Wrong. By the time you introduce a PHP "reboot", you're not going to get that "Don't Know That I'm Doing It Wrong" crowd anymore, and then who's your audience?
Writing a new programming language is fun, but don't expect it to replace PHP. That's going to be impossible unless your rewrite is shipped from php.net and replaces what exists now.
Writing a new programming language is fun, but don't expect it to replace PHP. That's going to be impossible unless your rewrite is shipped from php.net and replaces what exists now.
I wholeheartedly agree. "phpreboot" isn't PHP, it is a new programming language that looks similar to (or shares traits of) PHP.
I'm not sure how this gains traction associating itself with PHP. As a currently PHP developer, I'm certainly not going to hitch my wagon to something that looks to be a forked version of PHP.
The stated goals of this project aren't the ones I would have picked, but I'm sympathetic to the motivation behind it.
I think that a vastly cleaned up PHP (PHP6 or whatever) would attract the millions of loyal developers that PHP already has.
Many people just don't appreciate how much mindshare PHP has in parts of northern / central europe. And for those people it's not about $3 hosting, for them it's a proven workhorse language in which they can get things done on the web.
Not to mention that a business culture has grown up around these localised skill concentrations in which lots of businesses are now run on PHP.
I think when you say, "PHP has only one feature going for it: it already exists", you are vastly over trivializing steamroller-like traction and market penetration.
But if he's creating a new, unrelated language and calling it PHP, all he's doing is hijacking that "steamroller-like traction and market penetration" anyway.
"for them it's a proven workhorse language in which they can get things done on the web" ... which has a lot to do with its broad adoption (and thus easy hiring), and with certain software packages like Drupal, WordPress, Moodle and so on.
When has the elegance or power of a language ever been a consideration in the general business culture?
It hasn't been the case with Fortran or COBOL, IMO. And both are still used, despite being "dead," to maintain legacy systems that companies can't quite afford to replace yet.
Clearly, Facebook is in a different PHP area than your bog-standard $3/month crowd. Facebook has an advanced PHP tool chain that compiles PHP down to C++ (hip-hop)and they reap performance gains from that. They also built PHP repl (phpsh) because `php -a` sucks.
They use it cautiously and reluctantly because they don't have much choice at this point. The Asana and Quora founders ditched it at the earliest opportunity.
But to be fair, their PHP is a subset of the official PHP, and they probably use all of their own libraries (rather than the ones you have access to outside of Facebook).
So if you want Facebook to be your PHP success story, all you get out of it is "PHP didn't kill their company; they were eventually able to move away", which I suppose is not exactly a swimming endorsement.
Exactly. Most other web languages have this issue: You start from (1)"Here is how to do xyz. Fun huh" and (2)"Here is how you start working on your webapp."
Step 2 involves getting a server somewhere (as opposed to mamp or $3 hosting). Deciding on a framework (or no framework). Probably some command line stuff. etc.
With php, there is no step 2. Some of what you do in step 2 php programmers might want to do anyway (eg install a framework) but it's not necessary for starting out.
Upsides and downsides to that, I guess (I'm not a programmer) but that is core. If you could take that (MAMP-like installation, through your code into html, etc.) and use another language (including an existing one) I think you would have something.
- Bigger community, thus more resource documentation out there (Perl has Perl Monks going for it).
- More MVC frameworks (CakePHP, CI, Symfony, Lithium) vs. Catalyst.
- PHP has a cleaner syntax
I'm biased to PHP so of course I think it's better. For someone getting started with web development, I would recommend PHP over Perl. That is not to say that one should never "explore" Perl. Hell, Lawrence Livermore Labs uses a lot of it.
As Perl was developed originally as a scripting language for unix, it is fast, but I don't think it's well suited for the web (my opinion).
Plus, like the troll below me said (who apparently wrote a book on Catalyst, hence his bias), PHP was highly influenced from Perl, so if anything PHP is an alternative to Perl, not the other way around (like the OP mentioned).
I don't suggest Perl because I wrote a book on Catalyst. I wrote a book on Catalyst because I suggest Perl.
Anyway, here's what Perl has going for it:
* a larger group of core contributers
* an order of magnitude more modules (and module authors)
* Moose
* excellent Emacs support
* higher average level of proficiency among core team, and module authors
Ultimately, CPAN is the reason for using Perl. But after doing a lot of work in Python, I do really appreciate the things that Perl has built-in, too, like all-encompassing regexes.
Writing a programming language in this day and age and posting about it on HN is like visiting each denomination of your favorite religion and announcing that you're starting a new cult. Personally, I think it's a lot of fun, just don't expect a positive or welcoming reaction. Best of luck to you.
130 comments
[ 3.4 ms ] story [ 191 ms ] threadAlso, design a language with features, then think about the runtime. A language is not it's runtime.
Perl is older than PHP!
- Embedded sql in the fashion of php.reboot is dirty.
- No open/close tags and using brackets sounds error prone.
- I'm also personally a fan of the dollar sign.
It appears as though what you really want is Ruby.
That being said, my initial reaction is to wonder why, when designing a new language, one would model after PHP of all things.
1: http://en.wikipedia.org/wiki/Language_Integrated_Query
I think something like underscore.js[1] would be much more in the style of PHP - I always thought PHP and JS were similary in their wackiness - and I would much prefer it to LINQ.
As far as modeling after PHP, there are things I'd leave/take, but really the biggest issue is the standard library.
1: http://brianhaveri.github.com/Underscore.php/
May i ask why? i think that this makes the languaje very ugly.
In a language with sigils, that's no problem. It also makes it easier (therefore faster) for syntax highlighting to spot where variables are used, without needing a full dictionary and an exact version number - that makes a difference for me as an Emacs user especially.
- Happens very rarely - Is trivially solved, even in a large codebase
For me, it makes a big difference in languages like ruby where you could either be calling a method, a monkey-patched method_missing callable, or a property in some scope.
Additionally if your language has first class functions, it would feel kind of strange if names of some functions started with $ and others without it.
Take a look at the Linq implementation for a good example. Or, look at something like JSON in javascript.
I thought it was all kind of weird and wrong at first too but now it's probably my favorite c# feature next to the (very much related) lambda expressions, especially for non-SQL collection queries. Of course this doesn't mean PHP needs integrated queries or anything, but it is a very nice feature to have if done right. XML/json literals, on the other hand, do feel kind of wrong to me though (although I bet they are handy still, as many vb.net devs will probably attest to).
[Edited for spelling - damn ipad keyboard!]
Sometimes I even think it would be a good idea to half-ass it and just create a "wrapper" type library to map built-in PHP functions to namespaced and standardized (naming, parameter order, etc.) functions.
Then I usually wake up in the morning with a bad hangover and a deep sense of sadness.
It apparently "auto-protects" braces inside a script tag, but it's not clear how one would then embed phpr inside the javascript.
Right now it looks like a completely different language, and you might as well just give it an original name. I'm having a bit of a hard time seeing the connection to PHP here.
Basing a reboot on the JVM makes little sense in this context.
That said, you lost me at "less ';' like in javascript".
As horrible as PHP is, it is really easy to sit down with PHP and a tutorial or a book and start banging out code that gives you instant results. PHP is like the MS Basic 2.0 of the web era -- people who aren't really programmers (yet?) can sit down with it and GTD right away -- their code may be ugly but they can see it working as they go. They don't have to learn what a 'WAR' directory is and how it is structured, they don't have to mess around with xml configurations, etc. The ubiquity helps, certainly, but IMO the reason it got ubiquitous is how easy it is to go from nothing to "hello web world".
I think a project that maintains this instant GTD environment but improves the language is actually quite a good idea, though I also think cutting ties with PHP by giving it a new name makes more sense than calling it phpreboot and once you involve Java it seems less likely PHP's context-free easy start-up will be maintained.
It lacks a coherent design philosophy; it's a collection of hacks; a house of cards with no style. It's full of idiosyncrasies that must be memorized because they make no logical sense. Put simply, it completely lacks taste.
Which at the end of the day is the most common benchmark of utility.
If the answer to all of the above is PHP, then you're going to get projects done faster there than you would in Python or Ruby.
You could say the same thing about ASP, or even ColdFusion.
I'd argue that those instant results had more to do with the higher availability of PHP on cheap web hosts, than the accessibility of the language itself.
The people that don't like PHP's syntax already use other tools when they can, and when they can't, because they need to use PHP, it's likely going to be because they're using some existing PHP library or platform already (wordpress, drupal, etc).
I'm all for people experimenting and trying to make things better, but you're probably better off just making a new language than trying to make something that's sort of like php, but different enough that existing code libraries won't work with it.
If I was starting a green field project and had mostly PHP talent around I'd definitely consider using this.
I do also see http://www.phpforandroid.net/ but it doesn't look as ambitious as phpreboot.
Just convert and bingo, instantly deployable on 100% of php hosts. For local development, a script with --watch a la sass, or maybe a single index.php for converting things on the fly...
When I see special functions which exist to do basic array-as-list operations, like his `add()` function, my eyes roll. Then I see arbitrary, inconsistent use of the dollar sign to indicate variables and they start to bleed -- you either have a dollar sign or not, but pick one and make it work.
When the language designer adds features at whim, without considering whether or not his implementation is keeping consistency or breaking it, well that's how you get a language like PHP in the first place!
Native parsing of markup and SQL looks like a neat idea (reminds me of Facebook's XHP plus LINQ) but I'm concerned about using the JVM. Does this use a .NET style multithreading model instead of using one process per request? If not, I can't see the benefit of using a JVM given its best features (GC and JIT) would be rendered not only useless, but a bit of a drag.
My personal PHP wishlist is:
* Better interfaces for the core libraries. Ideally replacing them all with namespaced and object-oriented ones with none of this needle-hackstack mixup
* A standard autoloader
* Removing the concept of 'PHP errors' and replacing them all with exceptions
He's got a blog post here with some initial performance tests:
http://weblogs.java.net/blog/forax/archive/2011/09/04/hotspo...
Looks really fast when using type annotation (edit: faster than Java?!). Interestingly he is using the upcoming -hsx Hotspot server flag which makes a big difference in speed.
[1] http://asm.ow2.org/
If you want a better version of PHP, try Perl / Python / Ruby. If you want a language that can check your code for safety at compile-time, use Haskell. But if you invent your own language, it will have three problem: nobody will know how to use it, it won't be installed on any three-dollars-a-month shared host, and it won't have any libraries.
If you can't solve the "I want to use it for $3 a month" problem, your programming language is a failure compared to PHP. If you can afford more than $3 a month for hosting, then you're not using PHP anyway. Most people learn to program because they want to share something with their friends. They choose PHP because it lets them do that, and they don't have the experience to know that They Are Doing It Wrong. By the time you introduce a PHP "reboot", you're not going to get that "Don't Know That I'm Doing It Wrong" crowd anymore, and then who's your audience?
Writing a new programming language is fun, but don't expect it to replace PHP. That's going to be impossible unless your rewrite is shipped from php.net and replaces what exists now.
I wholeheartedly agree. "phpreboot" isn't PHP, it is a new programming language that looks similar to (or shares traits of) PHP.
I'm not sure how this gains traction associating itself with PHP. As a currently PHP developer, I'm certainly not going to hitch my wagon to something that looks to be a forked version of PHP.
I think that a vastly cleaned up PHP (PHP6 or whatever) would attract the millions of loyal developers that PHP already has.
Many people just don't appreciate how much mindshare PHP has in parts of northern / central europe. And for those people it's not about $3 hosting, for them it's a proven workhorse language in which they can get things done on the web.
Not to mention that a business culture has grown up around these localised skill concentrations in which lots of businesses are now run on PHP.
I think when you say, "PHP has only one feature going for it: it already exists", you are vastly over trivializing steamroller-like traction and market penetration.
When has the elegance or power of a language ever been a consideration in the general business culture?
Or rather, have no compelling reason to replace yet.
BTW: Many people would be amazed how much ADABAS + Natural still runs in government / banking around the world.
They use it cautiously and reluctantly because they don't have much choice at this point. The Asana and Quora founders ditched it at the earliest opportunity.
https://github.com/facebook/hiphop-php
So if you want Facebook to be your PHP success story, all you get out of it is "PHP didn't kill their company; they were eventually able to move away", which I suppose is not exactly a swimming endorsement.
What about, you can throw it into your HTML real quick and it'll work?
Step 2 involves getting a server somewhere (as opposed to mamp or $3 hosting). Deciding on a framework (or no framework). Probably some command line stuff. etc.
With php, there is no step 2. Some of what you do in step 2 php programmers might want to do anyway (eg install a framework) but it's not necessary for starting out.
Upsides and downsides to that, I guess (I'm not a programmer) but that is core. If you could take that (MAMP-like installation, through your code into html, etc.) and use another language (including an existing one) I think you would have something.
I'm surprised none has tried it.
Yeah. Right.
- Bigger community, thus more resource documentation out there (Perl has Perl Monks going for it).
- More MVC frameworks (CakePHP, CI, Symfony, Lithium) vs. Catalyst.
- PHP has a cleaner syntax
I'm biased to PHP so of course I think it's better. For someone getting started with web development, I would recommend PHP over Perl. That is not to say that one should never "explore" Perl. Hell, Lawrence Livermore Labs uses a lot of it.
As Perl was developed originally as a scripting language for unix, it is fast, but I don't think it's well suited for the web (my opinion).
Plus, like the troll below me said (who apparently wrote a book on Catalyst, hence his bias), PHP was highly influenced from Perl, so if anything PHP is an alternative to Perl, not the other way around (like the OP mentioned).
Anyway, here's what Perl has going for it:
Ultimately, CPAN is the reason for using Perl. But after doing a lot of work in Python, I do really appreciate the things that Perl has built-in, too, like all-encompassing regexes.