Just curious: who is using Pike for what?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Just curious: who is using Pike for what?

Arie van Wingerden
Hi,

as I am waiting for the Pike book to arrive (to have a quick start on Pike) I am wondering about the composition of the Pike community.

Would you please tell me what kind of work you do with Pike (and if possible what type of company you work for) and if Pike is the only language you are using?
Maybe also a bit on the pros (and maybe cons) of Pike?

Since I ask you, I'll tell a bit about why I came here ...
Well, I am a retired (Systems) Programmar (IBM mainframes) and always have enjoyed programming. A long time ago I wrote Cobol and RPGII. Later I used Assembler for some bits but mostly Rexx for most other things. Rexx was amazing, because it was so very well integrated in the OS.
Later on I started digging into languages, weighing the pros and cons and today I still do!
What I like to have in a PL is:
- readability
- power
- good integration with OS (read: a lot of great modules)
- possibility to develop fast (no long compilation cycles etc.)
- approachable GUI programming (not the C way)
So, I tend to develop fairly small programs in a few languages (like Python, Red or Go or now maybe Pike) and try to find out what I do (not) like and why that is ...

Best regards,
   Arie
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
On Mon, Dec 12, 2016 at 9:24 PM, Arie van Wingerden <[hidden email]> wrote:
> Since I ask you, I'll tell a bit about why I came here ...
> Well, I am a retired (Systems) Programmar (IBM mainframes) and always have
> enjoyed programming. A long time ago I wrote Cobol and RPGII. Later I used
> Assembler for some bits but mostly Rexx for most other things. Rexx was
> amazing, because it was so very well integrated in the OS.

Hey, that's cool! I'm a REXX guy too, although not on big iron - I
spent most of the 90s writing code on OS/2. GUI code in VX-REXX,
scripting code in straight REXX. Also wrote myself a MUD in C++, with
room code implemented in REXX.

> Later on I started digging into languages, weighing the pros and cons and
> today I still do!
> What I like to have in a PL is:
> - readability
> - power
> - good integration with OS (read: a lot of great modules)
> - possibility to develop fast (no long compilation cycles etc.)
> - approachable GUI programming (not the C way)

For readability, Python wins, hands down. It's the language I would
recommend as anyone's first. Python also wins a combination of
integration and fast development (C is better for OS integration, but
it's so much worse for fast development), with Pike a little way
behind. Pike and Python tie for power; some things are better
expressed in one and some in the other. GUI programming, though, I
absolutely choose Pike. It is hands down my favourite language for
that. Kinda weird since it's primarily a back-end language! So, now to
answer your original questions.

> Would you please tell me what kind of work you do with Pike (and if possible
> what type of company you work for) and if Pike is the only language you are
> using?

It's definitely not the only language I use, but it's my favourite. I
also use Python and JavaScript (and earn my bread and cheese by
teaching them), along with C (primarily to implement the above
languages), shell scripting, and a smattering of other languages on an
as-needed basis (eg Scheme only because Lilypond uses it, otherwise I
wouldn't bother).

1) GUI programming, as mentioned. I have a MUD client, a Twitch bot,
and (as yet unreleased) a mail client, all full-size apps with proper
GUIs.
2) Back end servers. I run a MUD (Minstrel Hall) written entirely in
Pike. It's what the language was originally built for, and it's easily
the best language I know for the job.
3) Text/data manipulation. Vies with Python for top spot at this; I
love sscanf's expressiveness, but Python has marginally better Unicode
support (eg upper/lower case that acknowledge the Unicode tables).
4) Simple, dependable scripting. Also vies with Python, but that's
because Python scripts are easier to distribute. (I can hand someone a
.py file and expect that Python will be either already installed, or
easily obtained. I can't be so certain with Pike.) My shed is full of
quick Pike scripts.

> Maybe also a bit on the pros (and maybe cons) of Pike?

Easy syntax for doing some operations across entire arrays. You can
look up and call methods on arrays of objects, you can use "automap"
syntax to quickly manipulate arrays of strings, and so on. Gets fairly
expressive:

rm(oldfiles[*]);
parts = replace(parts[*], "&", "&amp;");
return "Regions are: " + capitalize(sort(indices(timezones))[*])*", " + ....;

The last one multiplies an array of strings by a joiner string,
producing a single joined string. Very convenient. (And yes, you can
divide a string by a string to split it.)

Easy GUI management, and easy code reloading. However, put the two
together and you end up with something a bit messy and verbose, so I
put together a framework that makes it cleaner. But hey, even if you
have to build your own framework, you're still way better than most
languages offer you! Where else can you have a simple menu option that
downloads the latest code and applies it *immediately*, without
disconnecting you from the server or anything?

Heavily optimized. In a lot of cases, your code is compiled to machine
code, so it executes fairly fast. For a high level language, Pike
performs very well (I generally estimate that a Pike script will
outperform an equivalent Python script about 3:1). Obviously it's hard
to compete with C or Fortran for raw speed, but Pike is just so much
easier to use that I don't mind.

Downsides:

It's not well known. People don't know how to use it, so you need very
detailed installation instructions. Getting Pike set up on a Mac, for
instance, ain't pretty. (I *think* that installing Xquartz followed by
'brew install pike' will get everything, but I've had reports of
failures. So it's probably OSX version dependent.)

There are dark corners in the code. I've done work with GTK2 and some
other areas, and come across sections of code and documentation that
desperately need work. In terms of documentation, you've seen some of
it yourself. I guess that means Pike is... very open to contributions?
:)

Being a "niche" language, it lacks some of the features that other
languages can implement, as they have larger development teams. Python
and JavaScript both have generators now, which is awesome; but they
take a lot of dev time. Also on my wish list would be array
comprehensions, again paralleling Python's - there are times when
automap gets unwieldy, and it'd be awesome to have a better syntax for
those. But again, dev time. Someone's gotta write it, debug it, test
it, document it.

All in all, it's a language I love, and my GitHub reflects that. Not
the only one I love, and there are good reasons for choosing other
languages, but it's well worth having in the toolbox.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
>3) Text/data manipulation. Vies with Python for top spot at this; I
>love sscanf's expressiveness, but Python has marginally better Unicode
>support (eg upper/lower case that acknowledge the Unicode tables).

Can you expand a bit on the Unicode support part? Pike follows the
unicode table for the upper/lower case functions, but perhaps you are
referring to something more.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
In reply to this post by Chris Angelico
On Tue, Dec 13, 2016 at 12:30 AM, Martin Nilsson (Coppermist) @ Pike
(-) importmöte för mailinglistan <[hidden email]> wrote:
>>3) Text/data manipulation. Vies with Python for top spot at this; I
>>love sscanf's expressiveness, but Python has marginally better Unicode
>>support (eg upper/lower case that acknowledge the Unicode tables).
>
> Can you expand a bit on the Unicode support part? Pike follows the
> unicode table for the upper/lower case functions, but perhaps you are
> referring to something more.

Pike doesn't handle things like eszett:

> upper_case("ß") == "ß";
(1) Result: 1

Python does:

>>> "ß".upper()
'SS'

Also, Python has a 'unicodedata' module that allows name lookups and
such, although that's not a language feature. That's why I said
"marginally". I may have been slightly inaccurate about "acknowledge
the Unicode tables", as Pike's case conversions do seem to follow part
of them, but there are parts that aren't followed, so I'm not sure
what is and what isn't.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Henrik Grubbström-2
On Tue, 13 Dec 2016, Chris Angelico wrote:

> Pike doesn't handle things like eszett:
>
>> upper_case("ß") == "ß";
> (1) Result: 1
>
> Python does:
>
>>>> "ß".upper()
> 'SS'

That must be some Python-specific stuff; UnicodeData.txt from
Unicode 8.0.0 contains just the following entry:

   00DF;LATIN SMALL LETTER SHARP S;Ll;0;L;;;;;N;;;;;

ie no indication of an upper case variant. cf

   00E0;LATIN SMALL LETTER A WITH GRAVE;Ll;0;L;0061 0300;;;;N;LATIN SMALL LETTER A GRAVE;;00C0;;00C0

where the upper case variant is listed as 00C0.

> Also, Python has a 'unicodedata' module that allows name lookups and
> such, although that's not a language feature. That's why I said
> "marginally". I may have been slightly inaccurate about "acknowledge
> the Unicode tables", as Pike's case conversions do seem to follow part
> of them, but there are parts that aren't followed, so I'm not sure
> what is and what isn't.

Hmm.. adding support for looking up symbols by name to the Unicode module
wouldn't be hard.

  /grubba

--
Henrik Grubbström [hidden email]
Roxen Internet Software AB
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
On Tue, Dec 13, 2016 at 4:21 AM, Henrik Grubbström <[hidden email]> wrote:

> That must be some Python-specific stuff; UnicodeData.txt from Unicode 8.0.0
> contains just the following entry:
>
>   00DF;LATIN SMALL LETTER SHARP S;Ll;0;L;;;;;N;;;;;
>
> ie no indication of an upper case variant. cf
>
>   00E0;LATIN SMALL LETTER A WITH GRAVE;Ll;0;L;0061 0300;;;;N;LATIN SMALL
> LETTER A GRAVE;;00C0;;00C0
>
> where the upper case variant is listed as 00C0.

I think that answers the question. It's not Python-specific; it's that
there are two separate tables:

http://unicode.org/faq/casemap_charprop.html
ftp://ftp.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt

# The German es-zed is special--the normal mapping is to SS.
# Note: the titlecase should never occur in practice. It is equal to
titlecase(uppercase(<es-zed>))

00DF; 00DF; 0053 0073; 0053 0053; # LATIN SMALL LETTER SHARP S

So I was wrong about exactly what Pike and Python differ on, but there
is definitely a valid definition in the Unicode specs. Anyway, it's
still really minor :)

If I find myself a tuit, I might put together an importer from the
Unicode files into some sort of bidirectional lookup table for names
and codepoints (or characters). If I do, would an appropriate place be
String.uniname["FULL STOP"]=="." and String.uniname["."] == "FULL
STOP"?

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
On Tue, Dec 13, 2016 at 5:48 AM, Chris Angelico <[hidden email]> wrote:
> If I find myself a tuit, I might put together an importer from the
> Unicode files into some sort of bidirectional lookup table for names
> and codepoints (or characters). If I do, would an appropriate place be
> String.uniname["FULL STOP"]=="." and String.uniname["."] == "FULL
> STOP"?

Oh wait, forgot about the Unicode module :) So, should it be a
function, or a mapping? I'm inclined toward a mapping.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
>
>Oh wait, forgot about the Unicode module :) So, should it be a
>function, or a mapping? I'm inclined toward a mapping.
>

My suggestion would be to generate a mapping and put it into a
pmod-file that can be dynamically loaded when used.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
In reply to this post by Chris Angelico
On Tue, Dec 13, 2016 at 10:50 AM, Martin Nilsson (Coppermist) @ Pike
(-) importmöte för mailinglistan <[hidden email]> wrote:
>>Oh wait, forgot about the Unicode module :) So, should it be a
>>function, or a mapping? I'm inclined toward a mapping.
>>
>
> My suggestion would be to generate a mapping and put it into a
> pmod-file that can be dynamically loaded when used.

Sure. Umm.... How do I do that? The Unicode module is a cmod; putting
a pmod in the same directory doesn't work. Is there a way to put
something into lib/modules and make it appear as Unicode.Data? Worst
case, I guess I can make it Standards.Unicode, but the logical place
for it is the top-level Unicode module.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
In reply to this post by Henrik Grubbström-2
>On Tue, 13 Dec 2016, Chris Angelico wrote:
>>> upper_case("ß") == "ß";
>> (1) Result: 1

>> Python does:
>>>>> "ß".upper()
>> 'SS'

Discussed this with grubba Yesterday. I don't think upper_case should
do this. Besides sometimes (possibly supricingly) introducing more
characters in a string it would break the
    lower_case(upper_case(a)) == a
symmetry.

We should have a separate function for doing this in the Unicode
module, but I can't come up with a good name for
it. Unicode.upper_case() would not be particularly self
documenting. Unicode.special_upper_case()?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
In reply to this post by Henrik Grubbström-2
On Wed, Dec 14, 2016 at 10:05 PM, Peter Bortas @ Pike  importmöte för
mailinglistan <[hidden email]> wrote:

>>On Tue, 13 Dec 2016, Chris Angelico wrote:
>>>> upper_case("ß") == "ß";
>>> (1) Result: 1
>
>>> Python does:
>>>>>> "ß".upper()
>>> 'SS'
>
> Discussed this with grubba Yesterday. I don't think upper_case should
> do this. Besides sometimes (possibly supricingly) introducing more
> characters in a string it would break the
>     lower_case(upper_case(a)) == a
> symmetry.
>
> We should have a separate function for doing this in the Unicode
> module, but I can't come up with a good name for
> it. Unicode.upper_case() would not be particularly self
> documenting. Unicode.special_upper_case()?
>

The Unicode spec doesn't say that case conversions have to be
symmetrical. I don't particularly like the term "special", as it
implies that it handles _only_ the special cases; can't we use
"Unicode.upper_case"? In most situations, it's going to return the
same thing that upper_case does, so the choice between the two would
be down to whether you care about the string staying the same length,
or about the strict conversions.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
In reply to this post by Leif Stensson, Lysator @ Pike importmöte för mailinglistan
"Special" isn't clarifying that much either. Are there more examples
on how it will differ from the regular method? Also, is there a also
lowercase counterpart?

Some name suggestions:

 - upper_case_transform()
 - upper_case_expand()
 - upper_case_substitution()

(If the string may be shortened as well the 2nd one above isn't a good
candidate.)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
Interestingly, "ß" has a suggested uppercase in U+1E9E according to
Wikipedia [*]. Even more oddly, Pike fails to produce that while the
lowercase transformation works:

  Pike v8.0 release 209 running Hilfe v3.5 (Incremental Pike Frontend)
  > upper_case("ß")[0];                
  (1) Result: 223
  > lower_case("\x1e9e")[0];            
  (2) Result: 223

So this is at least one place where the roundtrip fails in one direction:

  > lower_case(upper_case("ß"));
  (3) Result: "ß"
  > upper_case(lower_case("\x1e9e"));
  (4) Result: "ß"

[*] https://en.wikipedia.org/wiki/Capital_%E1%BA%9E

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
In reply to this post by Leif Stensson, Lysator @ Pike importmöte för mailinglistan
There is things like

# Language-Sensitive Mappings
# These are characters whose full case mappings depend on language and perhaps also
# context (which characters come before or after). For more information
# see the header of this file and the Unicode Standard.

# Lithuanian retains the dot in a lowercase i when followed by accents.
# Remove DOT ABOVE after "i" with upper or titlecase
0307; 0307; ; ; lt After_Soft_Dotted; # COMBINING DOT ABOVE

which is going to require a locale argument.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
In reply to this post by Leif Stensson, Lysator @ Pike importmöte för mailinglistan
On Wed, Dec 14, 2016 at 11:20 PM, Jonas Walldén @ Pike  importmöte för
mailinglistan <[hidden email]> wrote:
> Interestingly, "ß" has a suggested uppercase in U+1E9E according to
> Wikipedia [*]. Even more oddly, Pike fails to produce that while the
> lowercase transformation works:
>

http://unicode.org/faq/casemap_charprop.html#11

Unicode follows the normal German usage and uppercases eszett to "SS".

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
In reply to this post by Chris Angelico
>The Unicode spec doesn't say that case conversions have to be
>symmetrical. I don't particularly like the term "special", as it
>implies that it handles _only_ the special cases; can't we use
>"Unicode.upper_case"? In most situations, it's going to return the
>same thing that upper_case does, so the choice between the two would
>be down to whether you care about the string staying the same length,
>or about the strict conversions.

Unicode.upper_case() is going to be confused with upper_case().

The choice would also be if you should apply locale specific
conversions. How does Python handle that?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
In reply to this post by Leif Stensson, Lysator @ Pike importmöte för mailinglistan
I would expect upper/lower_case to do the best thing for the output;
not to be symmetric or keep the number of characters.

I rather introduce a new call for that specific functionality.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
With my compatibility maintainer hat on that is a major
change. Potential compatibility problems:

* strings start changing lenght.

* lower_case() and upper_case() as used for normalization before
  string comparisons change. Granted, the change will sometimes be for
  the better, but still a change.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
In reply to this post by Leif Stensson, Lysator @ Pike importmöte för mailinglistan
On Wed, Dec 14, 2016 at 11:45 PM, Peter Bortas @ Pike  importmöte för
mailinglistan <[hidden email]> wrote:
> With my compatibility maintainer hat on that is a major
> change. Potential compatibility problems:
>
> * strings start changing lenght.
>
> * lower_case() and upper_case() as used for normalization before
>   string comparisons change. Granted, the change will sometimes be for
>   the better, but still a change.

If you're doing it for case insensitive comparisons, the true solution
is to add case_fold. The Unicode standard has strong promises of
backward compatibility regarding case folding, plus it's guaranteed to
be idempotent (unlike messing with upper- and lower-casing, which can
take several iterations to stabilize).

That would be a change in user-level code, though, so it'd be a new
feature rather than any sort of backward compatibility break. If
you've been using lower_case (or upper_case) on user input and then
storing the result, your code is *already wrong*, and an update to a
new version of UnicodeData.txt could break your code already.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Just curious: who is using Pike for what?

Chris Angelico
In reply to this post by Chris Angelico
On Wed, Dec 14, 2016 at 11:30 PM, Peter Bortas @ Pike  importmöte för
mailinglistan <[hidden email]> wrote:
>>The Unicode spec doesn't say that case conversions have to be
>>symmetrical. I don't particularly like the term "special", as it
>>implies that it handles _only_ the special cases; can't we use
>>"Unicode.upper_case"? In most situations, it's going to return the
>>same thing that upper_case does, so the choice between the two would
>>be down to whether you care about the string staying the same length,
>>or about the strict conversions.
>
> Unicode.upper_case() is going to be confused with upper_case().

They will do the same thing in all cases except where the length would change.

Personally, I would like upper_case to follow both sets of Unicode
rules, and then have 8.0::upper_case that maintains backward
compatibility. Then there's no confusion.

> The choice would also be if you should apply locale specific
> conversions. How does Python handle that?
>

Python doesn't. If Pike wants to, the Locale module would probably be
the place for it. It'd be nice to be able to say "lower-case this
string in the Turkish locale". The Unicode spec doesn't actually give
us that data:

"""
To make case mapping language sensitive, the Unicode Standard
specificially allows—but does not provide the necessary
data—implementations to tailor the mappings for each language.
"""

So I'd be fine with a locale-independent mapping, which means (among
other things) that "iıIİ" will lose information when case converted.

ChrisA

12
Loading...