161–170 of 263 posts
Earlier quoted context omitted.
Soon all dynamic languages will be one. Except for the method call syntax.
You mean all dynamic languages are Lisp?
Earlier quoted context omitted.
Soon all dynamic languages will be one. Except for the method call syntax.
Actually, that's Uniform Function Call Syntax http://www.drdobbs.com/cpp/uniform-function-call-syntax/2327... And it doesn't make a language 'dynamic'. The language I found with UFCS is both static and compiled.
What's left is [1,2,3]->slice(1,2) versus [1,2,3].slice(1,2)
ps: dynamic can be compiled and compiled can be interpreted, so I understand that it is unrelated.
Earlier quoted context omitted.
Curious about the hate. As far as languages go Ruby is as coherent as it gets.
All the reflection and abuse of mixins are pretty worthy of hate.
Earlier quoted context omitted.
Laravel alone was enough to bring me back to PHP. It seriously has made PHP exciting again (I come from a Codeigniter and Zend background). It takes all of the things people love about Ruby on Rails and brings them to a PHP framework utilising modern features like traits alongside the fantastic selection of packages like Cashier. The even more surprising aspect of Laravel isn't how great it is, but rather the fact it…
If you like it because it's like rails, why not just use rails? The rails ecosystem is undoubtedly stronger than laravel's, and it's a more mature framework. I don't see where laravel fits in the spectrum of PHP frameworks.
Earlier quoted context omitted.
There are languages that everybody hates, and then there are the languages nobody uses.
And then there is C#. ( implication being that I almost never see anyone hating on C#, and yet C# is really used a lot, obviously. Hey, I was probably gonna have to add this part to the post as an edit, anyway; might as well get it out of the way. )
Although I suppose one could rant about it being so deeply tied to Microsoft and the .net architecture.
Earlier quoted context omitted.
Laravel alone was enough to bring me back to PHP. It seriously has made PHP exciting again (I come from a Codeigniter and Zend background). It takes all of the things people love about Ruby on Rails and brings them to a PHP framework utilising modern features like traits alongside the fantastic selection of packages like Cashier. The even more surprising aspect of Laravel isn't how great it is, but rather the fact it…
> The even more surprising aspect of Laravel isn't how great it is, but rather the fact it was built by one guy ... using mostly 3rd party components, the majority from Symfony. So no, it's not "built by one guy".
It would be in the best interests of Laravel for Symfony to succeed, but you have to realise they're targeting two different subsets of users. I think what makes Laravel more appealing to me as a developer is it takes the good from the likes of Symfony, takes the great documentation and accessibility aspect from Codeigniter all while remaining a relatively soft opinionated framework, it provides you with a structure but the IoC container means you can structure it however you want. The Blade templating system is fantastic, the ORM is feature-rich and very powerful and the addition of database migrations right out of the box.
There isn't a lot of different between Laravel and Symfony considering they share similar components and the unique selling points of Laravel are components that can be used within a Symfony 2 application. I think Laravel gives you a little more out-of-the-box, whereas Symfony makes you add what you need and I can see the benefits from both sides of the fence. If you want to compare frameworks, a real comparison would be Laravel and Silex.
One aspect I like about Symfony is the ability to define routes 4 different ways; YAML, PHP, XML and Annotations in a controller. Compared to Laravel's routes.php file. If you're a developer that wants to customise absolutely every single aspect Symfony is probably a better choice, if you're happy with the guiding hand Laravel gives you out-of-the-box and don't care what format your configuration files and routes are written in (amongst other aspects), Laravel is the better choice. The learning curve of Symfony is far higher than Laravel due to the amount of configuration it allows you to do and the fact it is completely unopinionated.
So, while Taylor didn't build every aspect of the framework (a very well-known fact), there are certain aspects he did build specifically for Laravel. He also took the time to piece all of the components together from Symfony and other authors to create what is arguably one of the most developer friendly PHP frameworks since Codeigniter hit the scene in 2007. Before Laravel came along, I can't recall anyone else attempting to make a consumer friendly framework, can you?
Earlier quoted context omitted.
Nikita proposes methods on primitive types: http://nikic.github.io/2014/03/14/Methods-on-primitive-types... Myself, I like this proposal.
I like it too, it's clean. But reality is that PHP will have to be backwards compatible. Which means you will see old function based implementations and new object based implementations. Image dealing with both implementations within the same code base? Eek.
After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it. But the stdlib is still hard to manage. Different naming conventions, different order on the parameters for functions that do almost the same thing, and every function is global. Couldn't they keep all that for backwards compatibility, but create more sane wrapper…
Some other minor inconsistencies like array_map vs. array_filter are simply due to the fact that optional parameters have to be at the end of function calls. On array_filter the callback is optional, whereas on map you can map a list of arrays.
Earlier quoted context omitted.
Soon all dynamic languages will be one. Except for the method call syntax.
Actually, that's Uniform Function Call Syntax http://www.drdobbs.com/cpp/uniform-function-call-syntax/2327... And it doesn't make a language 'dynamic'. The language I found with UFCS is both static and compiled.
After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it. But the stdlib is still hard to manage. Different naming conventions, different order on the parameters for functions that do almost the same thing, and every function is global. Couldn't they keep all that for backwards compatibility, but create more sane wrapper…
Despite peoples grumblings about parameter order the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack. Once you know that its not that difficult. Some other minor inconsistencies like array_map vs. array_filter are simply due to the fact that optional parameters have to be at the end of function calls. On array_filter the callback is optional, wh…
There's a trick to this that isn't too hard to remember. Searching for a value in an array is much more akin to searching for a needle in a haystack.
So, for array functions, it's like searching for a needle in a haystack. For string functions, you're searching in a haystack for a needle.
I'm not really commenting on whether one should have to remember this, only that it helps if you need to remember it.