Actions from Rafaël Garcia-SuarezMovable Type Pro 4.382016-04-24T08:27:00Zhttp://blogs.perl.org/mt/mt-cp.fcgi?__mode=feed&_type=actions&blog_id=0&id=26Commented on The removal of the lexical topic feature in 5.24 in Reini Urbantag:blogs.perl.org,2016:/users/rurban//39.7434#17029172016-04-24T06:27:00ZRafaël Garcia-Suarez
mst: That was the intent of the _ prototype. However given the adoption rate of the lexical-topic feature, it's clear that was not a really wanted language addition...]]>
Commented on What prevent warnings pragma become default feature? in Yuki Kimoto Perl Blogtag:blogs.perl.org,2014:/users/yuki_kimoto//2020.6559#14830502014-12-10T08:20:37ZRafaël Garcia-Suarez
In short, warnings::register prevents it. In other words you aren't sure about the set of warnings that are going to be enabled implicitly.

Let me add that warnings are often used to detected edge conditions in the program environment (input etc.) while strictures control the program syntax and data flow, so enabling warnings by default everywhere might cause unwanted problems, even if it's generally a good coding practice. (This is also why using fatal warnings in production is an absolute no-go.)

]]>
Commented on booking.com - a toxic company for developers in booking employeetag:blogs.perl.org,2014:/users/booking_employee//2229.5501#13067162014-01-06T10:48:32ZRafaël Garcia-Suarez
There is in this post a part where the anonymous author personally targets me and questions the value of my work. I'll debunk the lies. No, I'm not active in hiring; no-one ever got an interview with me. I don't have a bonus on my contract. I communicate almost never about the company (I haven't gone to any conference in years and I don't blog much), and when I do, it's about the cool open source stuff that we write. Most of my time is actually spent on - surprise - my actual job: coding and solving technical problems, together with people that I appreciate and trust. I'm vain enough to take pride in my technical skills and I feel deeply insulted by insinuations that I would condone any sloppy practice (like copying and pasting code) or worse, the exploitation of fellow developers. And the friends and colleagues that are named, and many other that are not, feel insulted likewise, to be depicted like corporate bullies or like cheap code monkeys. Ah, and it's not that one "will see [me] trying to defend the company": here I'm actually defending myself against those degrading calumnies.

The rest of the article is just defamatory and slanderous bullshit. Haico debunked some of those already, notably the lies about the supposedly high turnover rate or the invention of the "continuous hiring" concept. I'll add that the point d about the kind of projects going to new devs is blatantly false, as any employee can see, and that the commission percentages that are quoted are also overestimated by a large factor, which *could* make me suspect that someone got paid to write this post to purposely hurt booking.com by spreading false information.

]]>
Commented on It’s the things we know that just ain’t so in Aristotletag:blogs.perl.org,2013:/users/aristotle//15.4267#3553032013-02-07T14:20:37ZRafaël Garcia-Suarez
Indeed.
]]>
Commented on The Case of the Incompatible Safe -- Epilog in Tom Wyanttag:blogs.perl.org,2012:/users/tom_wyant//506.3449#1706692012-07-02T09:15:17ZRafaël Garcia-Suarez
Cool! (But you really should thank Paul Johnson instead:)]]>
Posted Rvalue references to Rafaël Garcia-Suareztag:blogs.perl.org,2012:/users/rafael_garcia-suarez//22.31792012-05-01T07:25:29Z2012-05-01T07:29:42ZFrom the C++11 FAQ, section on rvalue references, about a simple incrementation function incr: If that incr(0) were allowed either some temporary that nobody ever saw would be incremented or - far worse - the value of 0 would become...Rafaël Garcia-Suarezhttp://blogs.perl.org/mt/mt-cp.fcgi?__mode=view&blog_id=22&id=26
From the C++11 FAQ, section on rvalue references, about a simple incrementation function incr:

If that incr(0) were allowed either some temporary that nobody ever saw would
be incremented or - far worse - the value of 0 would become 1. The latter
sounds silly, but there was actually a bug like that in early Fortran
compilers that set aside a memory location to hold the value 0.

That actually made me think about that nifty one-liner:

perl -wE 'Internals::SvREADONLY(${\undef},0);undef=42;say undef'

]]>
Commented on I was called "fucking asshole" in kmxtag:blogs.perl.org,2012:/users/kmx//156.3041#1362102012-04-05T07:55:49ZRafaël Garcia-Suarez
I guessed the identity of the offender before looking at the ticket. His communication style is so peculiar that many people are actively avoiding to pull his modules in their dependency chain, in spite of their usually good technical value. (Maybe there should be a module for that?) Let's not judge the Perl community from one single rather unrepresentative element.]]>
Posted Perl documentation word clouds to Rafaël Garcia-Suareztag:blogs.perl.org,2012:/users/rafael_garcia-suarez//22.29732012-03-22T09:28:58Z2012-03-22T09:34:05ZThis is totally useless, but I've written a script to create word clouds from perl's core pod files. As an example, here's the word cloud from perlunifaq :...Rafaël Garcia-Suarezhttp://blogs.perl.org/mt/mt-cp.fcgi?__mode=view&blog_id=22&id=26
As an example, here's the word cloud from perlunifaq :
]]>
Commented on Truth about Booking.com in BookingEmployeetag:blogs.perl.org,2012:/users/bookingemployee//1236.2902#1265092012-03-06T09:22:51ZRafaël Garcia-Suarez
Well, I work for Booking, the tables I work with have FK constraints, and I explicitly forbid people in my team to cut and paste code or going for other quick and dirty hacks that will hurt maintainability. On the other hand I work with business-critical data, so the overhead largely pays off, business-wise. So YYMV.

More generally there are quite a few very, very good Perl devs (and high-profile P5P or CPAN contributors) working for Booking. I doubt they would stay if they were paid only to churn out bad code and "not designing stuff".

]]>
Commented on Unicode and Passwords in Ovidtag:blogs.perl.org,2012:/users/ovid//11.2793#1195382012-02-09T09:49:54ZRafaël Garcia-Suarez
If your password comes from a browser, you have also the interesting problem to detect the encoding of the raw data you're receiving.

For your specific purpose, I'd choose a normal form (NFC probably, so stuff like the Dutch ĳ is not converted to i+j) and convert every Unicode input to that.

]]>
Posted Why Dart is not the language of the future to Rafaël Garcia-Suareztag:blogs.perl.org,2011:/users/rafael_garcia-suarez//22.22772011-10-11T10:10:14Z2011-10-11T10:13:39ZSo I've been looking at the Dart language specification recently published by Google (draft version 0.01). So far, I'm not really enthusiastic. Here's my reading notes. Class-based OO and Interfaces At first glance Dart code looks like Java (and nothing's...Rafaël Garcia-Suarezhttp://blogs.perl.org/mt/mt-cp.fcgi?__mode=view&blog_id=22&id=26

Class-based OO and Interfaces

At first glance Dart code looks like Java (and nothing's wrong with that, I'm not going to criticize a language based on my idiomatic preferences). The syntax is very similar, with the dot to invoke methods, the curly braces for blocks, the required semicolon to terminate statements, the main() function, the general feeling of verbosity. The familiar classes and interfaces are here. There is only single-inheritance, abstract interfaces being provided instead of full multiple inheritance to solve the diamond inheritance problem.

The spec has even a chapter on factories (static constructors). (Oh my, factories? it's like 1997 and design patterns all over again!) I should note that the integration of popular design patterns at the syntax level is disappointing: design patterns tend to emerge to work around a language design's weaknesses. Embracing them is a bit like admitting a design failure up front.

Let us just regret for the moment that more modern and useful OO paradigms, like roles, are not used here; as we have learned, interfaces are limited, since they do not allow sharing of code, only of method prototypes. But there are much more problems with Dart.

Feeble Typing

The spec says: Dart programs may be statically checked. The static checker will report some violations of the type rules, but such violations do not abort compilation or preclude execution.

Ah; OK. In other words the "static checker" is a lint-type development aid, not a language feature. Worse, that means you can write functioning programs with wrong (and misleading) type declarations, and still run them. Types have no effect whatsoever on your program's semantics.

The lack of type enforcement also implies that the runtime cannot take advantage of the typing information to optimize a running program (for example by pre-resolving method calls). Via some type decoration mechanism, one could have mixed weak and strong typing; instead, it looks like the Dart designers found that type inference was too hard to implement, so they completely gave up on the advantages that typing could have brought to the runtime.

Finally, this weak typing design removes the point of using interfaces at all. Interfaces don't allow to share code; so what's the point in adding them (and having them parsed and compiled in a browser at page loading time) if they are nothing more than a fancy documentation format? Interfaces make sense only in strongly typed languages (like Java), or else you're just doing duck typing like basically every dynamic language, but without the advantages of dynamic languages (runtime addition of new methods, or calling of methods by name, for example).

The design of Dart's OO system is not consistent. I'm calling it feeble typing. It's an unassuming weak typing that can't afford to be strong but does not want to be seen with the weak typing boys.

I understand that Dart is designed to be compiled to fast Javascript. The absence of type checking, in that context, feels like a premature optimisation, and we all know what it is the root of.

I note that Dart also supports function types (describing the whole function prototype, like in C). Their purpose is not clear, since there is apparently no way to manipulate function pointers; the interface Function (apparently used for anonymous functions) does not provide any method at this point. What is the point of function types if they have no runtime existence? Moreover, the fact that named functions and anonymous ("literal") functions are different entities is disturbing.

There are generics, too. Well, I guess that the example of C++ and Java hasn't discouraged the Dart designers. Again I don't see the point of generics without type checking.

Booleans

Here's a strange thing: the one and only true value is the boolean literal boolean true. Everything else is false. That means that code in if (1) { ... } will never execute, because 1 is a number, not a boolean, and there is no implicit conversion to boolean. You'll need to write if (1==1) instead.

The spec hints that it's because the boolean literals true and false can be autoboxed into objects, and as objects, they would be non-null, thus defined, thus true, if any non-zero value could be true. Looks like a lot of trouble imposed on the programmer for a very minor problem that could have been fixed at the language level by allowing boolean coercion overload, or by disallowing boolean autoboxing. (It is notable that Dart allows operator overloading, but not boolean, string or numeric coercion overloading.)

Another word of warning; the operators === (reference equality), != and !== (inequalities) all return a boolean; but == is not required to do so, because it can be overloaded, and (once again) there is no runtime type enforcement on its return value. Which means that the expression (a==a) might be, in some pathological cases, false. In my opinion, this is not something that should be allowed to happen in a well-designed language.

Type conversion

There is no implicit type conversion between numeric, string or boolean types. Integers and floating point numbers are distinct types. Objects that provide a toString() method (that should return a string!) can be converted into a string by interpolating them, as in int foo = 42; String bar = "${foo)";. The Math class provides methods to extract numbers from strings (parseInt and parseDouble).

The distinction between string and numbers allows to re-use the addition operator + both for addition and concatenation. However, without strong typing, this will almost certainly prove to be a bad idea. From the specs, it looks like "2" + 2 will be a concatenation, and 2 + "2" a run-time exception (in the absence of implicit conversion from string to number), but experience infirms this: string concatenation happens in both cases (although with a warning in the second one).

Exceptions

Speaking about exceptions. If we look at the list of standard exceptions, we see a proliferation of classes encouraging exception-based control flow. The programmers, being lazy, will naturally prefer writing catch-all NullPointerException handlers instead of testing whether their objects are null -- because the syntax makes it easier for them. (Constructs like if (a) a.foo(); will not work in Dart, see above.)

Another example: Ovid pointed me at the NoMoreElementsException, and added: "didn't Java programmers learn years ago that you throw exceptions for exceptional things and not for expected things?"

Isolates and heavy thread model

From the spec: Dart code is always single threaded. There is no shared-state concurrency in Dart. Concurrency is supported via actor-like entities called isolates.

Thus, isolates are a heavyweight thread control model very much like Perl 5's ithreads. That means that they are good for data isolation, but heavy to use and hungry in memory, because spawning a new isolate will imply cloning all the objects and data structures of the running libraries. (By the way, there is no word in the spec on cloning. Apparently Dart does not have the equivalent of Perl's CLONE() method.) There are also "light" isolates, which means that they run in the same thread than the object that created them.

(Isolates are probably good for browser-side security, although the spec do not talk much about that point -- disappointing again, security should have been in mind of the designers from the start, for a JS replacement.)

However, running in a browser is not like running in a server thread, and where Perl 5's ithreads might do their job, isolates are not adapted to web-page programming. Controlling the UI of the browser, with its high level of interactivity, requires a good concurrency implementation for event processing, lazy loading of resources, and animations. Dart is weak on that point: if you want to animate multiple widgets at once in the same HTML page, you'll need one isolate for each one, with all the implied overhead. Likewise if you want to do something while an ajax call is completing, etc.

Isolates communicate via message passing. It's not clear if there is some synchronisation method available in the standard libraries, semaphore-based or other. It's not clear either how the browser events are passed to the program. I need to look at the code examples; the spec is very much formal and not practical at all.

Security

Dart is lexically scoped and uses a single namespace for variables, functions and types. Dart provides private names, which are simply those beginning with an underscore; those names are not accessible outside the library where they are declared.

Dart provides library imports and source file includes. Not much more about it, the spec does not mention any kind of restriction about the places where code can be loaded. I suppose it will be in a future version. When importing a library, one can specify a namespace (or prefix) in which the imported names will be found, to avoid name clashes. It is not clear how Dart deals with second-level imports or recursive imports in this case. However the naming rules are clear and the removal of a global namespace was a good idea.

Conclusion

The worst of both worlds: Dart fails to provides the advantages of static languages, without compensating by the flexibility of dynamic languages. Nothing has been learned from the dynamic language renaissance of the last ten years; nothing from the functional world; nothing even from the slick concurrency model of Go and its goroutines, also from Google.

So I think it's a step backwards in language design. With Node.js and Coffeescript around, and the programming paradigms they allow, Dart looks already obsolete and inadapted.
]]>

Commented on Expanding Your MetaCPAN Author Profile in Olaf Alderstag:blogs.perl.org,2011:/users/olaf_alders//280.1992#290822011-07-20T07:23:38ZRafaël Garcia-Suarez
A few remarks to make it more awesome:
1. I can't find where to put my IRC nickname ?
2. What's the benefit of signing on with github ? It doesn't even add a github profile link. (Likewise for twitter)]]>
Commented on Failing your way to success with A/B Testing in Ovidtag:blogs.perl.org,2011:/users/ovid//11.1795#235692011-05-23T19:58:32ZRafaël Garcia-Suarez
Yes but what we really really want to know is, did your wife A/B-test this orange thing on her head ?
]]>
Commented on A Module::CoreList for vendor distributions in brian d foytag:blogs.perl.org,2011:/users/brian_d_foy//178.1517#196422011-03-02T18:46:00ZRafaël Garcia-Suarez
Porting/corelist.pl might be a start to collect data for such a tool, if anyone wants to pick that up.]]>
Commented on Perl101: Red to Green Gradient in Ovidtag:blogs.perl.org,2010:/users/ovid//11.1233#58242010-12-08T12:00:43ZRafaël Garcia-Suarez
This is quite a naive way to calculate colour gradients, since linear interpolation in the RGB space will yield colours that are not "between" the two limits neither in hue or in intensity. IIRC it's possible to get better results with the appropriate matrix multiplication related to the gamma of your display. Of course, being colour-blind, I'm not the most appropriate person to appreciate the quality of the result :)
]]>