LWN: Comments on "Scalar typing in the PHP world"

Poor arguments against

etienne — Thu, 12 Mar 2015 12:13:08 +0000

> asbestos underwear
> I would fail your abuse of knowledge of operators precedence in a code review, and force you to always add parenthesis to your code, lest you be removed from my dev team.

I may fail your (??abuse of??) reading and understanding English course.
I gave two C lines to show that "!=" and "^" cannot be exchanged without changing the meaning, even when simple case like "if(a != b){}" and "if(a ^ b){}" are obviously identical.

Poor arguments against

bronson — Tue, 10 Mar 2015 06:12:17 +0000

Beautiful and true.

Poor arguments against

mpr22 — Tue, 10 Mar 2015 00:44:31 +0000

A gentlebeing knows the complete order of operator precedence in C. A true gentlebeing is never so discourteous as to demand that anyone else do so.

Poor arguments against

ggiunta — Mon, 09 Mar 2015 21:33:48 +0000

Not sure if you mean this as a joke, or not, but given the general tone of this thread, I imagine everyone here is wearing their asbestos underwear already, so off we go...

I would fail your abuse of knowledge of operators precedence in a code review, and force you to always add parenthesis to your code, lest you be removed from my dev team.

Code is not supposed to be ascii art, and there is a definite limit to the benefits of terseness. Do you have a disease limiting your fingers movement? Maybe your keyboard has a couple of missing keys? What is the problem with 2 extra characters???

Someone else already stated above (or below) that code is meant to be understandable by humans first (meaning other beings than the one who wrote it in the 1st place), and execute correctly second. Amen to that.

With that off my chest, let me wax lyrical about how a bunch of extremely intelligent, highly trained, experienced developers, such as the majority of readers here surely are, seem to go nuts every single time discussions about programming languages arise (and systemd, but I think that wound will heal quicker than expected given a bit of time).
PHP is everyone's favourite scapegoat of course, but here it inexplicably got beaten to 1st place flamewar-topic by none the less than Perl! (while the Lisp gurus were somehow asleep in their caves and missed all the fun).

Is there anything we can learn from this?

Personally, what I think is that language design is not an exact science, and that we developers can not definitely not yet call ourselves engineers with a straight face. Otherwise there would not be so much disagreement, pure and simple. We're all still a bunch of artisans. Except the few ones who are truly just religious zealots ;-)

Poor arguments against

Wol — Sat, 28 Feb 2015 15:31:41 +0000

Actually, that's not true :-) Although it can get extremely confusing when working with scaled decimal that have decimal points in them :-)

Yes the internal representation has to be an integer, but as far as the programmer is concerned it can be "a number with 4 decimal places". And the poor programmer has to keep track of whether the string is "internal format" ie "10000", or "external format" ie "1.0000".

Given that it was used a lot for accounting, it worked quite well. Use internal format for pence, and external format for pounds. Just don't try to convert from internal to internal, or external to external ... I've seen a few bugs like that :-)

Cheers,
Wol

Poor arguments against

mathstuf — Fri, 27 Feb 2015 14:02:59 +0000

Also need a to be an integer.

Poor arguments against

renox — Fri, 27 Feb 2015 07:30:36 +0000

> my favourite language will happily let you multiply by 10 by concatenating a "0"

By 10 only if the number is base-10.. Hexadecimal number injection? Funny idea!

Poor arguments against

Wol — Thu, 26 Feb 2015 12:27:36 +0000

Shoudn't it be 13 - unlucky for some! :-)

Cheers,
Wol

Poor arguments against

Wol — Thu, 26 Feb 2015 12:26:01 +0000

> There is not reason to ever pass around an integer in the form of a string.

You've clearly never programmed in DataBasic, or Snobol, or various languages like that! (Or sqlite, come to that!)

The lack of type checking can be a real pain, but the idea that "all variables are strings" does have some real advantages. Not least, that when dealing with a real-world problem, it lets you apply a real-world solution without enforcing some compiler-writer's faulty idea of an axiom on you!!!

Cheers,
Wol

Poor arguments against

Wol — Thu, 26 Feb 2015 12:21:48 +0000

> Firstly, I don't really see the point in strict typing. There has never been a difference between "4" and 4 in PHP, and I don't see what adding one is going to accomplish, except a load of useless casts (in that the behavior of the code is exactly the same, so why bother) everywhere, making the code less readable.

Have you ever worked with a language with strict typing? Have you ever worked with a language with no typing? Have you ever worked with a language with optional typing?

Having done all three myself (and my favourite language will happily let you multiply by 10 by concatenating a "0" :-) I can tell you that, given optional typing, I usually crank it up to max!!!

Yes it can get in the way. Yes it's incredibly useful to be able to turn it off. Yes I love the fact I can use my human type "number" rather than faff about with floats, ints, doubles and reals. But as a developer, the ability to switch on strong typing and have the compiler check my work is worth its weight in gold.

Cheers,
Wol

Scalar typing in the PHP world

jospoortvliet — Mon, 23 Feb 2015 02:05:29 +0000

And then there is reality of course: http://blog.mailchimp.com/ewww-you-use-php/

(ownCloud is written in PHP and we are quite happy with it, too)

Poor arguments against

nybble41 — Sun, 22 Feb 2015 05:07:00 +0000

I realize this thread is getting way off topic, but the original point was about actual object leaks in Perl where objects with cyclic references will never be freed, even if none of them are accessible from active code. That is a good example of a problem with memory management, or rather a failure of the system to manage memory automatically. Dealing with cycles is one of the basic functions of a garbage collector; if you have to design your program to avoid them or risk leaking objects, you might as well be managing memory manually.

Anyway, the point was that the fundamental purpose of memory management is to recognize and free memory which will never be accessed throughout the remainder of the program so that it can be reused for new objects. In C++ all memory management is manual. Breaking cycles in Perl is something the programmer must do to ensure that unreachable objects get freed. That is low-level manual memory management. Redesigning an object storage system to better track object lifetimes is also memory management, albeit at a much higher level: an ideal garbage collector would recognize "reachable" objects which will in fact never be accessed regardless of the input and free them; manually removing the references is a hint necessitated by imperfect garbage collection.

On the other hand, I would not consider modifying an algorithm to compute a result a different way to be memory management, even though it may have an effect on the amount of memory required. Changes in evaluation order can have a fundamental impact on the nature of the program, to the point of altering whether it's computable at all within finite time. This is not to say that managing the order of evaluation in Haskell is any less work than managing memory manually in C++, just that it doesn't come under the heading of memory management. The equivalent task in C++ would be designing the algorithm, though in C++ it's much more difficult to defer evaluation, and you're consequently less likely to consider that option.

Poor arguments against

zlynx — Sat, 21 Feb 2015 06:08:48 +0000

This sounds like exactly the sort of arguments Java programmers start to make when their software takes up too much RAM.

"No, it isn't a memory management problem. We just happened to completely redesign the object storage system to better manage object lifetimes."

And you look at what they did and realize it would have been simpler to write it in C++.

Poor arguments against

nybble41 — Fri, 20 Feb 2015 05:50:31 +0000

I don't think most programmers would consider that "memory management". The runtime is still transparently taking care of allocating memory and freeing it when it's no longer required. It's not even a "space leak", really, since that would imply that the program is failing to free memory that it no longer needs. When non-strict evaluation results in higher memory use, it's because the inputs to an expression are larger than the final value—e.g. you need the sum of a long list and don't otherwise care about the contents. If you compute the sum eagerly then you can free the list and just store the sum, at the cost of potentially wasting some CPU time if the sum isn't needed later. Since the expression hasn't been evaluated yet, the inputs are still needed, and aren't being "leaked".

This is more about controlling the order of evaluation than managing memory. It isn't something which affects most programs, but it is something you have to be aware of when working in a non-strict language like Haskell, particularly when summarizing large data structures. Sometimes it works the other way, though; for example, `print (take 5 [1..])` requires constant memory (~1 list element) due to non-strict evaluation, whereas strict evaluation would demand infinite memory just to evaluate the `[1..]`.

Poor arguments against

mathstuf — Fri, 20 Feb 2015 04:34:53 +0000

So what do you call managing space leaks in Haskell if not "memory management"? Or is Haskell not high level?

Poor arguments against

HelloWorld — Thu, 19 Feb 2015 22:01:37 +0000

> In an interpreted language, I am not sure a variable should not be able to contain those strings:
Guess what, I am sure.

> "4kΩ", "2µm", "30℃", "70℉"
> "2$", "3£", "5$25¢", "450¥"
This has been possible for many years even in mainstream languages like C++.

Poor arguments against

HelloWorld — Thu, 19 Feb 2015 21:52:59 +0000

> Yeah, so? All programming languages have required knowledge.
This has nothing to do with being new to a language. It has to do with not solving a problem even though the solution is known and has been for decades. Anyway, I don't really care if you agree or not. A language that requires me to think about memory management is not high-level, period.

Scalar typing in the PHP world

smurf — Thu, 19 Feb 2015 21:17:39 +0000

These are two sides of the same medal.

A language whose designers (I use that word loosely) allow, or in fact appear to embrace, nonsense like the results of this snippet of code

<?php $a = ["123", "456A", "78"]; print_r([$a[0] < $a[1], $a[1] < $a[2], $a[2] < $a[0]]); ?>

(which shows that these three strings do not even have a consistent ordering) is fundamentally broken, sorry.

The problem is that the RFC does not mention that. It is solely concerned with function arguments but ignores the fact that the actual values are then still treated in an inconsistent manner, which IMHO makes the whole thing useless.

Perl6's ^^

marcH — Thu, 19 Feb 2015 15:25:31 +0000

High-level abstractions and fullness are good but "There is more than one way" goes too far beyond fullness. Fullness is not the point here.

Natural languages have redundancy, semantic overlap, fuzziness, assumptions,... These have pros and cons; one (limited) purpose: expressing nuances. In pure technical communications nuances are completely unnecessary; even harmful in programming languages and any specification. For instance a natural language like English is so poorly suited to protocol specification that readers typically complain that they feel like they are reading a new, foreign language.

For driving machines (including machines that could kill), a language model to follow is not natural languages but maths: high-level, expressive, very limited redundancy and most importantly of all: unambiguous. Who wants machines to do something... "maybe"? Merely changing the vocabulary is fine since this does not change the properties, however adding assumptions and/or redundancy only brings confusion with users constantly wondering about what they are reading.

[BTW you don't seriously think that a redundant and inconsistent ^^ operator brings Perl closer to natural languages, do you?]

Poor arguments against

mathstuf — Thu, 19 Feb 2015 15:07:39 +0000

That isn't operator overloading, but just user-defined operators (and AFAIK, they are specific to certain types). Overloading is doing things like "string + string" rather than having a separate operator for list concatenation. Anyways, SQL is (IMO) sufficiently narrow enough that dealing with these operators isn't that much of a big deal (then again, I very rarely write SQL, nevermind procedural SQL). Haskell is similar with the menagerie of operators available, but they're also usually confined to libraries rather than the language itself.

Poor arguments against

etienne — Thu, 19 Feb 2015 14:28:57 +0000

> There is not reason to ever pass around an integer in the form of a string.

In an interpreted language, I am not sure a variable should not be able to contain those strings:
"10³", "10E6", "12 ÷ 2", "¾", "⅒", "√2", "∛8", "1.25±0.01"
"MMXV" or "ⅯⅯⅹⅪ" (Roman numeral)
"𐹢" Rumi Digit Three
Maybe even:
"4%" , "4‰", "[1..1.25["
And for another type of "typing" that cannot be (easily) done with a compiler:
"4kΩ", "2µm", "30℃", "70℉"
"2$", "3£", "5$25¢", "450¥"
I am not sure I want to write the function "is_valid_integer()" myself, but the advantage of an interpreted language is that it could do the right thing at runtime, even if your problem is unusual.

Perl6's ^^

niner — Thu, 19 Feb 2015 07:31:58 +0000

Exactly! Code is a means to communicate with the next programmer and is almost incidentally executable by a computer. As you say, machines are machines and humans are humans. And humans understand human languages far better than machine code. Since the major goal is to communicate the intent of a piece of code to the next programmer that happens to read it, the fullness of a natural language can only help. And as a bonus, even the computer understands better what you're trying to achieve and thus has for example a better chance at optimizing.

Perl6's ^^

niner — Thu, 19 Feb 2015 07:27:14 +0000

^ creates a Junction: http://doc.perl6.org/type/Junction
^^ returns the first true argument if there is only one, and Nil otherwise.

Perl6's ^^

bronson — Wed, 18 Feb 2015 21:33:26 +0000

I still don't get it. In your example, you're using ^ as an infix operator. So why does ^^ exist?

I liked Perl5, and still have some modules on CPAN, but this sort of discussion is giving me the heebie jeebies... Perl6 seems to have a number of false friends (^ and xor) and subtle nuances to learn.

Perl6's ^^

marcH — Wed, 18 Feb 2015 20:19:30 +0000

> Another way to specify a junction is to use infix operators...

One of the most dramatic things Open-Source changed is the fact that code is read, reviewed, reworked and read again by many more random people from many more random places with many more random backgrounds and many more education and knowledge levels. From this specific perspective Perl (and I guess PHP too - dunno it enough) are missing the open source revolution, because of this completely off the mark "There is more than one way to do it" mantra.

No Larry, computer languages should not try to emulate the fuzziness of natural languages, absolutely not. Machines are machines and humans are humans; two very different things which complement each other and don't need to copy each other.

Perl6's ^^

niner — Wed, 18 Feb 2015 20:05:51 +0000

In Perl 6 ^^ is the infix operator version of the ^ junction operator.
Junction operators are: none, one (^), any (|), all (&). The infix operators behave accordingly. As such ^^'s behavior is indeed consistent with the other operators.

From Wikipedia:

List Operators

List operators construct a junction as a list:

my $options = any(1, 2, 3, 4); # Any of these is good
my $requirements = all(5, 6, 7, 8); # All or nothing
my $forbidden = none(9, 10, 11); # None of these
my $onlyone = one(12, 13, 4); # One and only one

Infix Operators

Another way to specify a junction is to use infix operators like we have already seen:

my $options = 1 | 2 | 3 | 4; # Any of these is good
my $requirements = 5 & 6 & 7 & 8; # All or nothing
my $onlyone = 12 ^ 13 ^ 4; # One and only one

Perl6's ^^

marcH — Wed, 18 Feb 2015 19:56:47 +0000

Assuming ^^ is useful, it should be part of some "list" module and given a full name and obviously not re-using the ^ symbol which is the traditional symbol for XOR.

Having the logic of this new ^^ operator somewhat related to XOR... yet different makes the re-use of the ^ symbol even worse: even more confusing, even more error-prone.

The unusual short-circuit logic which triggers only with 3 operands or more and the confusing effect of parentheses are the icing on the cake of surprises.

This looks like a futile exercise in code obfuscation; let's just stop beating a dead horse.

Perl6's ^^

bronson — Wed, 18 Feb 2015 19:41:55 +0000

Now I'm really confused. You're saying "Infix ^^" is some sort of logical operation that isn't xor but everyone will be confused because '^'?

The linked page says it, "returns the first true argument if there is only one, and Nil otherwise". How is that useful? Is it common enough to be worth making it an operator? I'd google but that would obviously be futile. :)

Scalar typing in the PHP world - RFC author quits...

corbet — Wed, 18 Feb 2015 18:54:49 +0000

The original RFC may be dead, but the idea lives on with different proponents. This looks like a story that will continue to run for a while yet.

Scalar typing in the PHP world

iabervon — Wed, 18 Feb 2015 18:45:45 +0000

It seems to me that, if the language has (1 + "1") = 2, it ought to provide to programmers the ability to use the language's built-in conversion tersely at the beginnings of functions.

I'm not sure that it makes sense for a function to control the ability of callers to get their data converted by the runtime going into the function; going from wrong-type input to the strict function, it will have to be converted or checked somewhere, and, unless the language doesn't have conversion at all, it will probably be converted using the language's built-in conversion, implicitly, somewhere pretty close to whatever insists that it already be converted, without any more extensive error handling than if no functions were strict.

On the other hand, having an easy way to ask for a pedantic conversion (where "1andjunk" causes an error if converted to an integer) would be useful, and not substantially change the language capabilities, since a library could always check that, if the argument is a string, it consists entirely of digits before converting it to a number.

Poor arguments against

mbunkus — Wed, 18 Feb 2015 08:59:44 +0000

True enough. I also compared two different sets of things here: ref-counted objects in Perl vs. normal objects in C++. Of course they behave differently. As soon as you use ref-counted objects in C++ (e.g. std::shared_ptr<>) the situation is much more like in Perl. So please disregard my previous comment; I shouldn't have sent it.

Poor arguments against

mchapman — Wed, 18 Feb 2015 08:34:30 +0000

> That's the point, Perl programmers need to think about this sort of things, and this is exactly the kind of thing that a high-level language should relieve one of.

Yeah, so? All programming languages have required knowledge.

Optimizing a language for new programmers is a losing strategy. You're only new to a language once.

Poor arguments against

mchapman — Wed, 18 Feb 2015 08:32:35 +0000

> I'm not sure this was meant, but unfortunately there are no such guarantees in Perl.

The documentation says:

"""
When the last reference to an object goes away, the object is destroyed. [...] If you want to do something when the object is destroyed, you can define a "DESTROY" method in your class. This method will always be called by Perl at the appropriate time, unless the method is empty.
"""

But Perl is what the perl(1) binary does, no matter what its documentation says. DESTROY is called from sv_curse, which itself is called by sv_free or sv_free2, the latter of which is invoked by SvREFCNT_dec if the refcount hits zero. People have been relying on this behaviour for years; it is unlikely to ever change.

Poor arguments against

mbunkus — Wed, 18 Feb 2015 08:30:50 +0000

In Perl 5 the following values are false in Boolean contexts: the number 0, an empty string, empty lists and arrays, undef and the string containing the single digit "0". All other values (including strings of any length > 0 no matter their content, e.g. "false") are true in Boolean contexts. The same is true in Perl 6 with Nil instead of undef.

Therefore in "true" ^^ "false" you have two trueish operands and therefore the result will be Nil.

Those strings are probably not the best and most self-explanatory when explaining Boolean concepts, though.

Poor arguments against

mbunkus — Wed, 18 Feb 2015 08:18:01 +0000

> In my experience, the benefits of reference counted objects outweigh these problems. For instance, reference counting gives you guarantees on when an object's destructor is called -- RAII is only half the story, after all.

I'm not sure this was meant, but unfortunately there are no such guarantees in Perl. Perl only guarantees that your object will be destructed sometime after its reference count has reached zero. This could be directly after its visibility ends. Or it could be at the end of the program. Or sometime in between.

This is very different from C++ where there are hard rules about when objects are destructed. I really love this about C++.

Poor arguments against

HelloWorld — Wed, 18 Feb 2015 08:08:25 +0000

> Perl programmers know that this is the memory model perl uses, so they write their code accordingly;
That's the point, Perl programmers need to think about this sort of things, and this is exactly the kind of thing that a high-level language should relieve one of. Cycles can hide in very surprising places.

Poor arguments against

niner — Wed, 18 Feb 2015 07:37:55 +0000

> Allright, I apologize if my admittedly rather blunt criticism of Perl and other languages hurt anybody's feelings.

Thank you!

> (I can see how operators like <$>, <*> and >>= can appear a bit scary at first)

Indeed. So we now have Perl, Haskell and PostgreSQL looking like line noise. Maybe that's not so bad a trait after all...

> How is it justifiable to call a language “high-level” when one has to worry about memory leaks through reference cycles?

Honestly, I think I've written only one application in almost 20 years of Perl where this was an issue and it's easily resolved by using weak references. Nevertheless Perl 6 does away with reference counting and uses a modern garbage collector instead.

> The convenience of Perl's // operator can be easily had in languages like Scala or Haskell, while the advantages of the latter (e. g. helping you keeping track of which values are optional and which aren't) haven't made it into Perl 5, and likely never will.

Yes, flexibility is a two edged sword. I would not discount Perl 5 though. If Perl has one advantage over the other commonly used languages, it's the ability to evolve. Perl went from ridiculously bare bones OO to one of the most advanced meta object protocols there are. And Perl 6 advances the ability to evolve even further. Aside from providing a decent type system, real method signatures and more.

> Perl's behaviour when nesting named subs (i. e. “Variable "$x" will not stay shared”) is confusing and useless

Yes, that's surely true, but again something one gets used to. And it's fixed in Perl 6.

> the utility of Perl's notion of “context” has yet to be convincingly demonstrated

I do find it somewhat useful at times, hurtful at other times. Perl 6's designers considered it too much of a confusion and replaced it by type coercions.

Haskell's design is heavily influenced by mathematics, while Perl's design is influenced by linguistics. It's only natural that these languages find fans in different audiences. That said, I think many people in #perl6 actually like Haskell.

Poor arguments against

mchapman — Wed, 18 Feb 2015 00:34:23 +0000

In my experience, the benefits of reference counted objects outweigh these problems. For instance, reference counting gives you guarantees on when an object's destructor is called -- RAII is only half the story, after all.

Perl programmers know that this is the memory model perl uses, so they write their code accordingly; they know when they need to explicitly tear down cyclical data structures or mitigate the problem in some other ways, such as by weakening particular references. It simply isn't a big issue.

Perl6's ^^

rgmoore — Wed, 18 Feb 2015 00:28:36 +0000

Actually, it looks as if that doesn't make it inconsistent, because Perl 6 has done away with the built-in bitwise operators. Now, &, |, and ^ produce Junctions with different properties. And Junctions, made by joining with &, return true on a test only if all items in the Junction return true for the test, Or Junctions, made by joining with |, return true if any item returns true, and One Junctions, made by joining with ^, return true if exactly one item returns true. So ^^ returning true if exactly one item is true is consistent with ^, just not with the way ^ and xor worked under earlier versions of Perl.

Poor arguments against

marcH — Wed, 18 Feb 2015 00:22:54 +0000

I thought "false" was false (why did you use it?!)