(no title)
fs2 | 6 years ago
- Everything is either built-in or can be enabled from an OFFICIAL repository (like functions for bc,xml,etc). No more trusting sketchy npm packages or having to pull in a ton of dependencies that might stop working some day.
- It's so fast and elegant to consume a (SOAP or REST) webservice. Visual Studio insists on creating tons of files, obscure web.config settings and other misc. stuff. PHP handles this in a couple of lines.
- Development feels natural, every file can be a single class if you want and there are plenty of highly matured frameworks available.
I estimate I've slashed development time in half compared to C#, less bugs and less security issues (verified through two independent code auditors). Even large projects are easier to work on in PHP compared to C#
pathartl|6 years ago
If I'm going to consume a web service, I am going to write the models in C# and let a JSON deserializer like Newtonsoft.JSON map everything. To me, there's nothing better than having a fully modeled web service. I learn a bit about how the service works when writing the models. I know what the data looks like before I start working with it in my own application.
Regarding your web.config note, I guess I don't understand what you're trying to get at. .NET projects tend to throw configuration items into, well, a configuration file. Again to me this is far superior to doing the PHP-industry-standard of having a config.php and chucking a bunch of global variables into it. Putting configuration items behind a parser in a document that you expect the user to edit is good practice.
Development feels natural, every file can be a single class if you want and there are plenty of highly matured frameworks available.
Maybe this is a note more for the NodeJS space, but a single file per class is the general guideline for C#/.NET. Additionally, I've generally found that the .NET framework and libraries written against it tend to be of much higher quality, are more secure, and are more production ready than most I've worked with in PHP land.
On top of that, Visual Studio is a wonderful IDE and is pretty much the gold standard of our industry. I've not had a better experience as a developer than being able to create a .NET Core MVC web application and hit the ground running. I've written anything from 5 line Azure Functions to working with 100k+ line web applications and I'm not sure I could have done it without the excellent debugger available and the very context-aware Intellisense typeahead. In contrast, other than PhpStorm, I find PHP environments to be extremely messy and a bit of a hack to get working properly. If I didn't have some sysadmin background I'm not sure I'd move outside of "debugging" using var_dump().
I was a PHP dev primarily from ~2009-2017 and have been working almost exclusively in C# since.
9dev|6 years ago
We do have config files too - global variables in some config.php was already frowned upon 10 years ago, much more so today. In times of autowired DI, you have a parsable, user-editable config file just like any other project. Had you used PHP since like 2013 or newer, you'd be aware of at least Symfony, which does this since forever.
I don't know a single reason why you would put multiple classes in a single file, especially in times of PSR-4 autoloading. Nobody does this since years, much rather decades, ago.
I also really don't know which libraries you use, but the composer ecosystem is one of the most mature, best maintained out there. There are countless projects of excellent quality out there, used in production on millions of servers every day.
Speaking of IDEs: you mention PHPStorm but still claim there's practically no good IDE for PHP. That doesn't make any sense: PHPStorm is a top-notch IDE, it has virtually anything you have in VS.
And lastly, why would anyone still bother with setting up an environment on their box if we have Docker? It's 2020, there's really no more reason not to.
fraktl|6 years ago
Unless you've a solid proof, this is just.. blatant lie. How did you measure the security and quality? Was it "ok, this seems nice" or was it literally reading the code, running the tests and hitting the lib with a pentest suite?
See, it's one thing to compare languages (which is silly) and completely another to let your subjective feel get in the way of objective analysis.
Stating that libraries which contain more than 1 class per file are more secure and robust is just a nice wish, but nothing more than that. It's simply not true to the point it's funny :)
> On top of that, Visual Studio is a wonderful IDE
It sure is, top notch IDE.
> In contrast, other than PhpStorm, I find PHP environments to be extremely messy and a bit of a hack to get working properly.
You've PHPStorm and there's VSCode. PHPStorm is better. It works almost flawlessly. What's an IDE got to do with environment? Why are they a hack?
I'm a dev who started with PHP in 1998. and have been using it since (among many other languages). Reason I'm writing this (despite hating it) is to nullify your experience as any sort of valid argument.
Unless you can provide actual, hard proof for what you wrote - it's merely how you'd like it is.
Now, is any of that important? It's not. You use C# and you're satisfied. That's all that matters. If some other guy says PHP is better - you know that it's not, in your particular case. And that's great.
IMO, as a PHP dev, I consider C# an excellent language. As a sysadmin, I hate Windows and its ecosystem from the bottom of my soul.
pbowyer|6 years ago
I would never choose PHP to consume a SOAP webservice if I could use C# or Java instead. And I say that as someone who's been consuming SOAP with PHP since 2001, from travel industry suppliers, major CRMs/ERPs and a bunch of quirky services.
PHP's SOAP library just isn't very good. From what I recall it doesn't support some of the security extensions natively, struggles with namespacing, has small changes to data structures when serializing/deserializing (I recall attributes/values being a pain to setup) and worked with some endpoints but not others. That could be the endpoints' fault, but when Microsoft is producting it - I sure expect the endpoint to work with PHP's bundled SOAP library.
Multiple times I fell back to constructing the XML myself (sometimes with the DOM builder, other times with handcrafted XML strings that were tested in SOAP-UI until they worked and given placeholders for data.
Last week I had to investigate ow a service had got the wrong data, and neded to load the XML response again to see the data in our app. The PHP XML extensions give a different structure to the SOAP extension; to get back the result you have to mock the response in a subclass of SoapClient, feed in your XML and let the extension parse it. That works, and is elegant in a way - but it could be so much better.
Rant over ;)