Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Bet the farm. Python or PHP?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 106 posts

Re: Ask HN: Bet the farm. Python or PHP?

#61

Post by zain »

t0pj wrote: post #21
yourabi wrote: post #10

Go with Python. PHP is probably the worst language I've had to use (Single namespace, poor unicode...) Python on the other hand is pretty cool. It can be OO, functional, or procedural depending on how you want to look at it. It also has a lot baked into the standard interpreter and has some really awesome frameworks (Django, Pylons)

Single namespace in PHP - Ouch. You can gracefully get around this with classes perhaps? Any thoughts on PHP frameworks? On Python, I've heard that TurboGears is a pretty good framework as well. I remember reading somewhere that you don't run Django, it runs you. Any fiction in that?

"Any thoughts on PHP frameworks?"

CakePHP is a powerful, popular one. It gives you Ruby/Django's famed MVC in PHP.

Re: Ask HN: Bet the farm. Python or PHP?

#62

Post by systems »

jrockway wrote: post #50
natch wrote: post #41

Earlier quoted context omitted.

Perl is more readable to someone who knows Perl, because it gives you indications what type each variable is: $ for scalars (single values without dimension) @ for arrays % for hashes (like python's dictionaries) With python, you have to guess. Of course, many people who are intimidated by Perl have made the same statement about readability, and it is often repeated unthinkingly. That doesn't mean it's true. On the o…

because it gives you indications what type each variable is: Not really. Guess what type $foo is in each case: my $foo = []; my $foo = {}; my $foo = "Hello, world."; my $foo = \"Hello, world.";

while completely ignoring the right hand side, i can tell they are all scalars.

Looking at the right hand side, I can tell the type of the value in that scalar type! ... the value type is a different thing than the variable type

We can really debate and argue about the value of typeful variables ... the value seem to be that it allow a combination of syntactic sugar and availability of the reference type!

So basically, if you want a reference type, you need syntax to dereference the reference.

And if you have that, you will eventually need syntax sugar for when you dont want to use the dereferencing syntax.

This is probably why in Perl things are the way they are!

I am not sure thought if the reference type is at all needed, it some occasions I see it clarify cases when values are passed by reference vs passed by value, because a reference in Perl is a real value, not something that is implied! ... but this i would say is largly subjective

Re: Ask HN: Bet the farm. Python or PHP?

#63

Post by SwellJoe »

jrockway wrote: post #50
natch wrote: post #41

Earlier quoted context omitted.

Perl is more readable to someone who knows Perl, because it gives you indications what type each variable is: $ for scalars (single values without dimension) @ for arrays % for hashes (like python's dictionaries) With python, you have to guess. Of course, many people who are intimidated by Perl have made the same statement about readability, and it is often repeated unthinkingly. That doesn't mean it's true. On the o…

because it gives you indications what type each variable is: Not really. Guess what type $foo is in each case: my $foo = []; my $foo = {}; my $foo = "Hello, world."; my $foo = \"Hello, world.";

The whole references thing is the biggest pain in the ass in Perl syntax. List flattening, and the fact that arrays and hashes can only store scalars (or a reference to something else), etc. just expands into every nook and cranny of the language.

I still have a hard time with this aspect of the language after 10 years of Perl coding (with a three year break where I mostly worked with Python). And given how strong the tools in Perl are for working with hashes and arrays (grep, map, join, splice/unsplice, shift/unshift, sort, etc.) it really is a pain point. Perl 6 fixes many of the painful bits but not all.

But, nonetheless, I'm more productive in Perl than any other language. Partly because of the massive library of excellent pre-existing code, and partly because my problem domain almost always involves text parsing/processing and dealing with system-level data which are things for which Perl was designed.

Re: Ask HN: Bet the farm. Python or PHP?

#64

Post by SwellJoe »

neovive wrote: post #42
t0pj wrote: post #21

Earlier quoted context omitted.

Single namespace in PHP - Ouch. You can gracefully get around this with classes perhaps? Any thoughts on PHP frameworks? On Python, I've heard that TurboGears is a pretty good framework as well. I remember reading somewhere that you don't run Django, it runs you. Any fiction in that?

Coming from a Perl background, you would probably be more comfortable with PHP. Definitely checkout the KohanaPHP framework (www.kohanaphp.com) for a solid, well-designed PHP5 MVC framework, With a good framework, you can write very readable and maintainable code.

I come from a Perl background and I'm definitely not more comfortable with PHP, despite having used it quite a bit over the past year or so for our company website, forums, store, etc. Python at least has first-class functions, and I had no problem using it for a few years when I was working in a Python shop (and I still miss IPython which rocks so hard...Devel::REPL is not quite an acceptable substitute). But, I find Ruby the most palatable of the currently trendy languages (though I do almost all of my work in Perl)...I was able to sit down and write working Ruby code with fewer bugs than I can with Perl, and I've been using Perl for 10 years. Python, after three years, I found my bug count was roughly the same as I write in Perl.

Re: Ask HN: Bet the farm. Python or PHP?

#65

Post by SwellJoe »

bayareaguy wrote: post #22

Why two web servers (thttpd and apache) instead of just one, say lighttpd or nginx?

Or just Apache. Apache serves static content faster than the vast majority of us will ever need, and dynamic content as fast as Lighttpd or nginx, in general (because the slow part is the code in Python, or PHP, or Ruby, or Perl). Run WSGI or mod_fcgid or mod_rails, or whatever, so your interpreter only spawns once, configure Apache appropriately, and you'll be fine for all but the most insane loads.

Re: Ask HN: Bet the farm. Python or PHP?

#67

Post by jrockway »

SwellJoe wrote: post #63
jrockway wrote: post #50

Earlier quoted context omitted.

because it gives you indications what type each variable is: Not really. Guess what type $foo is in each case: my $foo = []; my $foo = {}; my $foo = "Hello, world."; my $foo = \"Hello, world.";

The whole references thing is the biggest pain in the ass in Perl syntax. List flattening, and the fact that arrays and hashes can only store scalars (or a reference to something else), etc. just expands into every nook and cranny of the language. I still have a hard time with this aspect of the language after 10 years of Perl coding (with a three year break where I mostly worked with Python). And given how strong th…

And given how strong the tools in Perl are for working with hashes and arrays (grep, map, join, splice/unsplice, shift/unshift, sort, etc.) it really is a pain point.

Not really:

  my $ref  = [qw/foo bar baz/];
  my $ref2 = [map { uc } @$ref]; # [qw/FOO BAR BAZ/]
References, if anything, are just slightly ugly. I could live without non-reference values, however. They're basically useless, but sometimes they make the program more concise.

I think everyone realizes this mistake, however, and Perl6 only has types that behave like references:

  my @foo = split '/', "foo/bar/baz";
  function(@foo, 'hello');

  sub function(@foo, $string){ ... }

Re: Ask HN: Bet the farm. Python or PHP?

#69

Post by Xichekolas »

t0pj wrote: post #21
yourabi wrote: post #10

Go with Python. PHP is probably the worst language I've had to use (Single namespace, poor unicode...) Python on the other hand is pretty cool. It can be OO, functional, or procedural depending on how you want to look at it. It also has a lot baked into the standard interpreter and has some really awesome frameworks (Django, Pylons)

Single namespace in PHP - Ouch. You can gracefully get around this with classes perhaps? Any thoughts on PHP frameworks? On Python, I've heard that TurboGears is a pretty good framework as well. I remember reading somewhere that you don't run Django, it runs you. Any fiction in that?

Not sure if first class functions matter to you, but last time I checked, PHP didn't have them, which is a major annoyance for me.

I also find PHP to be quite the cognitive overhead. The libraries seem to lack consistent naming conventions and since it's all one global namespace, there are a LOT of names to remember. Coding in PHP often feels like repeatedly looking up library functions and 'assembling' them, rather than 'writing' something.

Re: Ask HN: Bet the farm. Python or PHP?

#70

Post by jrockway »

systems wrote: post #62
jrockway wrote: post #50

Earlier quoted context omitted.

because it gives you indications what type each variable is: Not really. Guess what type $foo is in each case: my $foo = []; my $foo = {}; my $foo = "Hello, world."; my $foo = \"Hello, world.";

while completely ignoring the right hand side, i can tell they are all scalars. Looking at the right hand side, I can tell the type of the value in that scalar type! ... the value type is a different thing than the variable type We can really debate and argue about the value of typeful variables ... the value seem to be that it allow a combination of syntactic sugar and availability of the reference type! So basicall…

I don't understand most of your post (too many ...s that aren't clear), but you should probably stay away from the word "type" when you are talking about Perl variables. "Scalar" doesn't really mean anything. If anything, it describes the cardinality of the contained value, but certainly not the "type".

Even values stored in variables have very flexible "types" that I wouldn't really call a "type".

If you store "42 is a number" in a scalar, you still don't have a type. Maybe it's a string, maybe it's an integer, maybe it's a boolean. Types only show up when you apply an operator. If you say "42 is a number" - 42, then the result is 0 because "-" coerces the string into an integer (actually a SvPv to an SvPvIv, and then looks at the integer part of the data structure). This is different from other languages that choose the operator based on the type of the value (look at how SBCL chooses the right + operator to used based on the types of the contained values. the exact opposite of Perl).

As an aside, this coercion isn't an implementation detail; Perl exposes it all to you. If you "use overload", you can have "boolify" subroutine called when someone does "!$your_object", a stringify subroutine that's called when someone does "$your_object =~ /.../" or "qq{$your_object}", a "numify" subroutine that's called when someone does "$your_object - 42", etc.

Anyway, not sure what my point is... but don't use the word "type" to talk about values or variables in Perl. It just doesn't make sense. Perl is totally different from other languages here, and the word "type" has too much incompatible baggage associated with it.

Post reply on HN