Also, is it only an interpreted language or can I compile it too if I want?
Is it like Ruby in the sense that I have to share the whole runtime with the ruby script or can I somehow share a standalone cross-platform executable?
I’ll be honest, the design decision at first hand sight did not look that exciting
string name = Stdio.stdin->gets();
It did say it was like C so the design decision you don't like is C
I'm fine with C. Keep the focus on Pike.
It is understandable though, considering this language is 30+ years old. Probably not the decision you would make if you were to design it today: Switch statement with labels+fallthrough instead of a switch/match expression (even Java replaced that one with a switch expression nowadays), ?: ternary operator instead of if expression (the Pike docs even call that one ugly and recommend not using it)...
And today I still can't.
Legacy projects?
There’s literally no reason to use this language unless you want to make MUD games or are just purely curious about the project.
Being an offshoot of an existing MUD language it was quite usable even a young language, comparably good performance and a compelling C embedding. History could very well have been different. The 90s was a really good decade for dynamic languages.
So when we went to go do "serious" work we kinda missed them.
Your options in 1991, 92, 93 were earlier perls, shell + awk/sed, or maybe tcl or a lisp/scheme if you were lucky.
The languages inside those MUDs actually were ahead of their time, and their programming model -- in the case of MOO [and its offshoots CoolMUD and ColdMUD] at least -- was more similar to advanced systems like Smalltalk or Self which were hot interesting topics at the time.
Being "confined" to being "game" languages made them not get taken seriously (unlike "JavaScript" which arrived with all sorts of weird warts but had Netscape's brand on it), so the LPC people tried to make it into a "serious" language in the form of Pike, and it's not half bad?
By the late 90s, obviously things had changed. If somebody in a successful "serious" company had adopted Pike/LPC it could easily have had an alternative history where they became commonly used instead of perl5 or php on the early web. (It took Python a decade to get serious headspace there.)
(Gratuitous plug for my LambdaMOO defibrilation: http://github.com/rdaum/moor)
And the builtin one I wrote in mooR is built to be pluggable (Rust trait) so should be possible to swap it out.
https://pike.lysator.liu.se/docs/tut/introduction/first_glan...
(saving you some clicks...)
But ./configure && gmake && gmake install seemed to work, or at least it runs and nothing weird has happened so far.
https://en.wikipedia.org/wiki/Roxen_(web_server)
EDIT: Github repo https://github.com/pikelang/Roxen
It seems that these are (unsound) type hints, years before TypeScript made them cool:
> "If your program tries to put one type of value in a variable which was designed to hold another type of value, Pike may detect this" [emphasis mine]
https://pike.lysator.liu.se/docs/tut/fundamentals/index.md#t...
At least it might be shooting Nulls.
Also you'd think having the type signature would help with performance, but in some cases it can cause the VM to enforce a runtime type check where it wouldn't have before, imposing worse performance.
A more subtle issue with type hints (as in TypeScript/Python, not sure if this applies to Pike) is that there are ways to work around the type system. You can get, for example, a variable of type `int` that actually holds a `list`:
These guys were deep in the MUD.
Early web sites, gopher, etc were just request/response mostly static content (sometimes with a dash of a database). They weren't synchronous or "live" in any real way. Things like IRC were synchronous but did not do programmable/dynamic content.
I cut my teeth on moo, and was bored & annoyed to tears writing cgi scripts in Python & Perl and the web didn't catch up to produce really interactive stuff until well over 10 years later ("web 2.0")
At the time the alternatives were stuff like Tcl and Awk and Perl 5, which were relatively clunky, incompetent or slower. Perl won for web, though Pike had Roxen and could have, and if that had happened we would likely have gotten a more Smalltalk-like Internet than the PHP Internet we got.
Pike is fun, it will likely compile just fine on your odd computers if you have any and it has some characteristics that are uncommon like easy hot upgrades for long lived systems and modules as data.
So long ago, that it took me a minute to recall having programmed a lot of CGI code with it, back in the Roxen web server[3] days.
1. https://en.wikipedia.org/wiki/Pike_(programming_language)#Hi...
pike is suitable for large high performance standalone applications. basically everything that you would use python for as well but faster.
pike is also still under active development and maintenance, so far from dead.
* The Roxen web server
* The Opera Mini backend service (150k CPU cores, 5k servers, 150k pageloads/s, 3 million inline fetches per second, 100+ Gbit/s - 15 years ago)
I worked on both of those projects. Now I mostly program in Python. It's perhaps like 10x slower to run on average but since it won there's a module or three for anything so building stuff is faster.
Yay progress.
I was just browsing the "Module tree reference" for Pike. There seems to be a crazy amount of modules for the language. Weirdly enough for web there's only CGI (and WebSockets for some reason), and the CGI module isn't really documented. Under protocols there seems to be everything I ever need.
But we were too busy having fun building the language to "market" it. This became a pattern.
On the web dev front, Python was lucky to get easy bolted-on async I/O (via greenlets), so it was more performant than Ruby (which was really slow 10 years ago), and Django was less magical than RoR.
python likely caught up and overtook pike because it had better community support. one downside of pike is that it is slow to start, making it less convenient for quick scripts, which python was a lot better at, so pyton was more likely to replace perl in sysadmin work where short scripts matter more further helping its popularity.
airstrike•6h ago
cess11•6h ago