http://www.perlmonks.org?node_id=1022413


in reply to Threads and signals in Windows

It sounds like you are a MSWindows promoter and are trying to alter Perl's development to suit Windows by taking away all the useful Unix tools ... how is that being cross-platform? Why should Unix/Linux developers give a damn about Window's problems? After all, most of our so-called cyber-security dangers come from the widespread use of the inferior Windows OS.

I say phase out MSWindows, and move everyone to Linux.

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Replies are listed 'Best First'.
Re^2: Threads and signals in Windows
by bojinlund (Prior) on Mar 11, 2013 at 08:45 UTC
    zentara thank you for your comment!
    It sounds like you are a MSWindows promoter and are trying to alter Perl's development to suit Windows by taking away all the useful Unix tools ... how is that being cross-platform? Why should Unix/Linux developers give a damn about Window's problems?

    No, I am NOT a MSWindows promoter! However in many cases I have been forced to use Windows and I am mainly a user of it. I want, as you, Perl to be cross-platform and I do not want to remove any thing!

    Not all modules need to be portable between the different implementations of Perl. However I want it to be easy to develop a portable module. If you want to write portable code you need to consider the limitations of the Perl implementation in all the intended target systems. The current Perl documentation gives very little support to avoid non portable constructs. But even with good documentation many non portable function will been used by mistake. This is one of the reasons for my sometimes non realistic proposals.

    When I started to use Strawberry Perl http://strawberryperl.com/ I got the possibility to install modules from CPAN. I was a big improvement for me. The downside was the difficulties to know which module can be used in Windows.

    The Windows operating system seems to have less good resistance for programming errors. Installing some CPAN modules degenerate the Windows system and it has to be repaired. This is especially a problem running smoke test on Windows.

    The fact that your system can be harmed by installing Perl modules, can and probably will, give Perl bad reputation.

    So I believe Unix/Linux developers should give a damn about Window's problems at least when developing portable modules.

[reply]
      When I started to use Strawberry Perl http://strawberryperl.com/ I got the possibility to install modules from CPAN.

      That is such a clear indication of someone who doesn't know anything about Windows.

      I've been installing from CPAN for years; but I don't use Strawberry Perl.

      Using SP doesn't make it easier to use CPAN; or Perl. It only makes it easier to pretend you aren't using Windows.

      And that is counter productive because it just means that people blames Windows for the limitations of the Perl port to Windows.

      Which means the Perl Port never improves because the blame for problems is wrongly attributed.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      The current Perl documentation gives very little support to avoid non portable constructs

      perlport

[reply]

        From Re^5: pipe fork win32 about the documentation of fork in Windows.

        its actual behavior isn't well-enough (at all?) documented to allow for a set of rules to be written down about what will and won't work.

[reply]

In Section Meditations