Live data from Hacker News

PHP Addiction

marco.org

291–300 of 320 posts

Re: PHP Addiction

#291

Earlier quoted context omitted.

But the problem is MySQL and PHP are objectively, measurably much worse than the alternatives you have listed. Cool-ness biases are perhaps not so easy to distinguish from justified ones.

I'd like to extend your claim to Redhat as well. I won't make the comparison directly to Ubuntu, but I will compare it to Debian. And in the realm of server-oriented tasks, Debian is hands-down a better option, from the point of view of a sysadmin. I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating…

While I also find Debian to be net superior, I'd say Redhat is nowhere near as bad in comparison to its alternative as PHP, or even MySQL.

Re: PHP Addiction

#292
post #129

The only thing actually wrong with PHP, is that it's popular but not cool. And that's a terrible place to sit for any product. It runs half the Internet quite well, but if you went by the posting on HN, you'd think it was Windows Vista. I've probably read every article critical of PHP that has hit the front page of HN in the last few years, and the one thing they all have in common is the vague refrain that PHP is a…

> The only thing actually wrong with PHP, is that it's popular but not cool. No, what's "wrong" with PHP is that other things that are better have come along since. That's not a fault of PHP, that's the nature of language evolution. > It runs half the Internet quite well COBOL runs tons of mission critical business services quite well. It doesn't mean that nobody's improved on COBOL or that you should use it for a ne…

I guess that what bothers most of us oldtimers is that better things have existed all along! :-)

better = in a better "programming language design" sense only

Re: PHP Addiction

#293
post #209

Earlier quoted context omitted.

Python and Ruby are both general purpose languages, and both also run on the JVM. Knowledge of Java can be useful though, as terrible as the language is.

Python and ruby are just scripting languages - Java is a structured type safe language which is battle hard. No comparison!

Don't be silly. All three languages are of similar maturity (in fact Python is even older than Java) and all three have been "battle tested".

The only thing you might argue is that the JVM is a better runtime than CPython or CRuby, and for that there's JRuby and Jython.

Re: PHP Addiction

#294
post #154

The fear of making the "wrong" choice actually makes the familiar, mastered PHP more attractive. The multi-core reality means that the long-term languages will have a strong concurrency model. Clojure and Go are two languages with strong concurrency models that are building momentum and have potential to go mainstream. But for your first foray out of PHP, I would pick a language that has a large, well-established com…

If your goal is to work at Google maybe. If your goal is to become independent and wealthy, perhaps not.

What would your path be?

Re: PHP Addiction

#295
post #79

Earlier quoted context omitted.

Just by looking at a syntax table, the higher-level differences are not going to be enumerated. Just off the top of my head: - Ruby was always designed as an OO language, whereas Python OO was bolted on later. Ruby's object system is almost a straight transplant from Smalltalk and is very powerful. - Python lambdas can only be one liners. Ruby lambdas can be arbitrarily long. Guido doesn't really like FP - there's no…

While I find Ruby to be nice overall, you're wrong on several points: - Whether or not Python was historically OO or not, everything in Python is now an object. Its love for protocols drives design like `str(foo)` (which calls `foo.__str__()`), not any particular deficiency in its object system - Python's lambdas are indeed limited, but one can easily use `def` and just name the function. Functions are first class, a…

Personally, I find that Python and Ruby are comparable as it relates to utility. I'd think it is fair to say that argument is a wash. It is Ruby's expressiveness that makes it my choice before Python:

--- Ruby ---

  letters = ['a', 'b', 'c']
  letters.map &:capitalize
--- Python ---

  letters = ['a', 'b', 'c']
  capitalize = lambda x: x.capitalize()
  map(capitalize, letters)
--- PHP ---

  
Of course, this is one example where PHP (5.4+) at least somewhat resembles Python. I think that is why some of the more experienced PHP developers tend to choose to go with Python as their PHP recovery language.

Personally, I prefer "letters.map" (Ruby) over "map(...)" and "array_map(...)"; however, that is a personal style preference and has nothing to do with technical merit. And I still enjoy writing Python here and there. PHP is also still a necessity much of the time.

That being said, there are a few edge cases that I've witnessed where Python actually reads better than Ruby; though, these cases are few.

Re: PHP Addiction

#296
The PHP problem for me least is always available of existing projects I can modify. The last thing I did was an availability calendar and I soon found a perfect opensource one already written in PHP. A few customer specific modifications later, and I had finished my task. I did look for one in python, but didn't find anything. If I had to write one from scratch, it would be in python, but why reinvent the wheel?

Re: PHP Addiction

#297

I'd suggest switching to JavaScript (or CoffeeScript) instead of Python or some other trendy language. a) You need to know it anyway. b) Node.js is awesome and works the way web servers ought to work. c) JavaScript, if you avoid the obvious warts, is a really nice language. Every other language I've learned either has as many warts as JavaScript or isn't practical. Having picked JavaScript, it turns out to be amazing…

> Every other language I've learned either has as many warts as JavaScript or isn't practical.

Time to learn some more languages.

Re: PHP Addiction

#298
Well, there's a solution.

Do not write every part of a project in only one language. Following the UNIX "Small is beautiful", most projects can and are cut to small things that work together.

I often find myself writing a library in Python and publishing it's API in web.py, building services that rely on this API in Node.js, and making the final website in PHP.

Re: PHP Addiction

#299
post #241
post #98

Earlier quoted context omitted.

Yes, but... All languages (like any system) will have cruft, after a while. Is the solution really to do a periodic break with backwards compatibility for purity reasons, Python 3 style? There should be a better way?! What about a low level machine like Java/.Net and just let the next language evolve on top of that -- so old libraries could run? (Maybe there could be Xcompilers for Ruby/Perl 6/xxx to the Perl "byteco…

Some things simply can never be fixed. Figuring out when that happened to you is a judgement call.

List them out, explain them, show your work...

If us PHP developers have such bad judgement, show us the error of our ways.

And do not link to some other persons blog post - explain it yourself.

Re: PHP Addiction

#300
post #121

Is it my imagination or is Marco the king of writing blog posts that are quick reactions to whatever is trending on HN? The message you should get from this post is that familiarity with one's tools easily trumps any aesthetic flaws (consistency in parameter ordering, naming conventions, etc are really nothing more than aesthetic flaws and not "deep" [1] as the author suggests. After all, human language is inconsiste…

I'm actually quite the opposite, I've been a long time Linux user (Fedora, Ubuntu, Debian, and more recently Arch) and recently I decided to dive head first into OSX for work and play. OSX is beautiful, it's smooth, and it can run a lot of my games too. But, just like Windows, it lacks functionality. Setting up a MAMP server with my required PHP extensions for work was an absolute nightmare even with Homebrew. Even w…

Keep homebrew for standalone tools (recode, sntop, whatever). Then use rpm for ruby, perlbrew for perl, pythonbrew for ... And setup the defaut macosX apache (which has php5.3 and pear and whatever already here) work for your user account. See : http://echodittolabs.org/blog/2011/09/os-x-107-lion-developm...

Same on any nix system I use : sandboxing is the way.

- Want to use hg-git for mercurial, dont, homebrew that !! Build it in your ~/bin/ or in your $HOME sandbox, give all PATHS in your $HOME precedence, and rejoice.

- need mysql, postgre,... Don't homebrew that !! Either build it, or use the Macos dedicated installer with propper service installation, on dedicated port.

- etc,...

All in all, Homebrew, Fink and Macports are great for one thing : showing you how to patch the default tgz, saving the user hours of work for his custom, sandboxed install of any software (which as itself has been a life saver, for myself, on many an occasion).

Macos still is, as far as i'm concerned the best laptop platform for someone who has to use licenced software (external job/office constraint) but also needs a nix (bsd) environment. Otherwise, what can't you do with the default Ubuntu 12 LTS (i guess you agree) ? Macos, sure, is's on its way to become worthless as The Lion slowly sandboxes the user out of the OS, but tat's another story.

EDIT : and let it be said that OF COURSE, I agree with you that aptitude, yum and the like have no decent equivalent on the Apple/Microsoft closed platforms.

Post reply on HN