Thoughts On The Pike Programming Language?
bilboyablan asks: "Ive stumbled upon the Roxen Web server , mostly implemented in the
Pike programming language.
I got curious about Roxen, but even more about Pike, and it seems to me like a quite solid scripting OO language, with a C-like syntax, and with a quite good documentation (user manual) to boot. So it seems intriguing to me why Pike hasnt gotten a wider acceptance.
So, if some of you fellow Slashdotters have had any experience with Pike (outside of Roxen), could you maybe drop a few lines on it?
"
Ok, moment of honesty: I've never heard of it. Could someone please post some information? Or some urls? Any alternative to perl (which I DO use a lot and appreciate, but. . .) would be most welcome.
-S
http://students.washington.edu/steve0/
steve0@u.washington.edu
- - - - - - - -
Don't worry, being eaten by a crocodile is just like going to sleep in a giant blender.
Pike has Gtk bindings too and my (limited) experience with them has been good. Seems like a pretty cool language. There's a good Pike resource site at http://www.pike-community.org/.
-moibus http://moibus.jfm.net/
Sure it's decent, but what does it have that's special? Learning any new language is a significant investiture of resources and time, and if there's nothing special about it, why spend the time? Might as well spend the time learning something new that you know is "bankable".
i've used pike quite a bit since i first discovered it. its great-- support for many platforms, better OO than any other scripting language, pretty strong threading support-- and i wouldnt hesitate to recommend it, especially to those comfortable with C.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
Hark, one more language
A powerful new system
Named after a fish
According to the pike web site, it is a high-level interpreted language, syntax similar to C, and has an "image processing module" capable of producing anti-aliased text and can do other drawing operations (image scaling, etc). It has a crypto toolkit and can interface with SQL databases. It's even GPL'd and works on quite a few different platforms. Looks like it's from Sweden.
Sounds pretty cool to me.
As stupid as this sounds, not having windows support that's readily available in the form of a downloadable binary is a big blow to the language. (actually, last I checked a while back, not even the source was officially supported ... I haven't tried compiling with Cygwin / GCC.)
Sure, we're talking about the OS from hell created by Satan himself here, but since it's widely used, not supporting it well bites ya.
I don't like Pike, but I definitely like the Roxen Webserver. It is also GPL, and I use it as much as I can. Roxen supports PHP4 now, and I like that better for web development.
I played around with Pike for a while, and my gripe with it is that it is too C-like. At least what I want out of scripting language is a high-level environment like Perl or Python. Of course, horses for courses.
When C was introduced it quickly won the hearts of computer programmers as a high level language that still feels like a low level one (close to Assembler memory management.) It was not like Fortran, Ada or Basic, it allowed something that was never there before C. We have C++ that can do all that C does, we have Python and Perl that can do somethings in more convenient ways, there is Java and VB etc.
How easy is it to introduce a new language that will catch up with the masses? Java and Python are good examples of such languages. Java allowed many programmers do what C++ does in the sence of OO but easier to learn, Python has the power of Perl plus it allows use of other language libraries. These are clearly improvements (no I am not saying Java is better than C++, I am saying there was (is) a market for this language for those who want some (not all) power of C++ and they want it fast and easy to learn).
Maybe in order for a language to become widely accepted it must present something new from marketing point of view not only from functional point of view.
Still it is not impossible that pike will find its own audience. How many of you use ML, Prolog, Lisp or Scheme in your everyday life? But these languages have their own purpose, their own market niche, mainly AI R&D.
If Pike has something new to offer, it'll be used.
You can't handle the truth.
There is a Win32 binary download right there on the Pike download page. Granted, the install process wasn't your typical windows GUI install, but was nonetheless painless and simple. Good thing you checked it out before you said something.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
The world's largest amateur fantasy and sci fi art/writing site is powered by it. Every page is automatically generated by pike whenever one of the thousands of artists on board update their page. The URL is http://elfwood.lysator.liu.se and yes, I'm a member (though my gallery shall remain anonymous as my intention here is not to plug myself though I will say I joined when there was less than 100 people involved) and a voulentier staff member on the webpage.
I'm not sure, but I THINK that Roxen and Pike were created at the Lysator computer club at Linkopeg university in Sweeden, who as you can see in the above link, are hosting Elfwood. The URL for the Lysator computer club is http://www.lysator.liu.se Of course, there's a high probability of me being wrong about that being where Roxen and pike came from.. but I seem to remember that's what someone told me.
well that is a strange statement. Most script languages are hard to use for those who do not know how to use them.
Here is another one: Unix IS user-friendly, it just chooses its friends very carefully.
Why are scripting languages hard to use? I use sh, csh, ksh, awk, sed, Perl, Python, jsp, asp and even Dos batch files in primitive basic. What is so hard about 'em?
Translated languages under Unix/Linux have the same precedence level as compiled binaries (under DOS bat files are secondary). Translated languages don't even have to be compiled! It is true that I have not seing a good IDE for awk or csh but it does not mean the language is bad.
You can't handle the truth.
Only without the years of development, the thousands of freely available modules, the extreme flexibility, the massive cross-platform portability (you can configure perl for your toaster), integration with Apache, Database support, tens of thousands of existing experts and freely available sample scripts, a huge set of some of the world's best programming language documentation, and (let's not forget) its own poetry (what other language can claim that?), having the core built by one of the coolest people on earth (read and laugh!).
Maybe Pike is amusing, but next to a language like Perl, is it really needed? And can you really claim that Pike has "character" when you can't even write poetry? (Yes, I am a Perl bigot.)
BTW, Hello world in perl? perl -e 'print "hello, world\n";' on the command line will do the trick. Ha!
David E. Weekly
David E. Weekly
Code / Think / Teach / Learn
h4x0r for
It's reminiscent of LPC, the language found in the popular line of mud known as LP. I would not be surprised if it was based on LPC.
Not just fish or sticks.
There are brilliant people
from which this name comes.
it would help if i actually knew how to talk...
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I looked at the links and also checked through Google, but from what I can see it's very similar to CLIPS, moreso than PERL.
More race stuff in one place,
than any one place on the net.
thanks, I guess I have fans?
Kirk
Catalyst, I am
Ever posting in poems
Check my User Info
Yes thats right, it's made in Sweden. By some people at university of Linköping. (Probably the best univ. in Sweden when it comes to computer-related education.)
UNIX is NOT user friendly if you don't do the things that UNIX doesn't like. Windows is not friendly if you don't do the things that Windows doesn't like. If rm -rf * is your style, the UNIX is your game. If right-click->Delete is your style, then BeOS is your bag. Windows is only your bag if you need to run a program. If you're running a server, good luck if you try to do it in windows. If your running a desktop, god help you if you try to run it on UNIX. I am quite experianced with Linux, but it still amazes me how much crap I have to put up with to do simple desktop things like install a new 3D card driver. (I'm not kidding by the way, it is ridiculously easy in Windows. More so in BeOS where the system automatically installs drivers.) Of course I've dabbled in networking, and am amazed at how easy UNIX makes it.
A deep unwavering belief is a sure sign you're missing something...
hahah, dude, that's awesome
I wish it was harder. So many languages today claim to be "easier to learn than C", but that appears to be their only advantage. Once one learns to program, what good is such a language?
From "On Lisp" by Paul Graham:
"Not so long ago, if you asked what Lisp was for, many people would have answered 'for artificial intelligence.' In fact, the association between Lisp and AI is just an accident of history. Lisp was invented by John McCarthy, who also invented the term 'artificial intelligence.' His students and colleagues wrote their programs in Lisp, and so it began to be spoken of as an AI language. This line was taken up and repeated so often during the brief AI boom in the 1980's that it became almost an institution."
The truth is that Lisp (and its dialects) is an extraordinarily versatile and powerful language. It is suitable for just about anything, including operating system design (people have and are still writing great operating systems in lisp) and application programming (emacs anyone?), especially involving embedded scripting languages. The features which make Lisp unique (first class functions, lexical closures, powerful macros, etc. etc.) also make it able to adapt to practically any problem in computer science and solve it both elegantly and efficiently.
Perhaps more than any other language, Lisp has taken a bad rap as of late, usually by people who haven't put any effort into learning it, or worse yet, people who have never tried it at all. I challenge those of you who took Lisp for granted as some sort of "AI language" to actually try it for yourself. At first you may find it awkward to adapt to Lisp's style of programming, but eventually you'll come to realize that the reason you felt awkward was because what you were doing before was not a very good method of programming or problem solving in general.
-W.W.
"Well it should be obvious to even the most dim-witted individual who holds an advanced degree in hyperbolic topology...
Where are closures?
If you wonder why I mention them, then you have never tried functional programming techniques.
Regards,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Trifles make perfection, and perfection is no trifle. -- Michelangelo
Lambda expressions ain't closures.
Tom Christiansen recently made the very interesting point that any programmer who has not been exposed to all of the imperative, objective, functional, and logical styles has one or more conceptual blind spots. In his words, "It is like knowing how to boil but not to fry. Programming is not something you master in 5 easy steps."
Perl smoothly supports building real system in any and all combinations of those programming styles. This is no small feat, even if it wasted on most of the monkeys currently giving Perl a bad name by pumping out glorified print statements...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
The major difference between java and pike is that pike does not have a formalized byte-code syntax (at least not yet).
This makes saving bytecompiled files on disk hard, you have to compare the pike version used to dumped the file with the version you are running, if they are different, you have to dump them again.
So it is not currently possible to distribute pike programs without source-code (unless you also distribute the pike version that should be used to run them)
The pike compiler also does quite a lot of optimizations, both on the syntax tree generated by the bison (LR) parser, and a peephole optimizer that works on the generated bytecode.
So, what I wanted to say really is that pike is interpreted in exactly the same way that java is. interpreted.
Basically it is closer to Java than to scripting languages because of the declarations. It might be simpler to use than Java if, for instance, you used the "mixed" type (can hold any object) everywhere, because you don't need casts ; it still looks heavier than Tcl, Perl or Python.
This might be a problem for commercial software (like Blender), or for free software not GPL-compatible.
Does Lisp have referential transparency, or does it allow side effects and sequenced statements? Does it have an advanced type system, which supports type checked algebraic types (advanced generic typing)? Does it have universal lazy evaluation? Does it automatically curry functions?
Lisp is old hat, my friend. If you are going to preach to us about expressive programming languages, pick something more up-to-date. At least you have ventured beyond the "C is everything" mentality... too bad you got stuck in the 1970/1980s, with Lisp. Lisp has great historical value, but other than that, it has been out classed by Haskell, www.haskell.org
Cute little Object Oriented scripting languages, like Pike, are cool and all, but other than their aesthetic value, they add very little to advanced programming languages. It is yet another Object Oriented PL
However, I have to say that I'm impressed with the eye toward performance in Pike (most of the Roxen webserver itself is written in Pike), and the responsiveness of the maintainers when it comes to supporting the product.
I don't know what "referential transparency" means. Yes, Lisp allows side effects and sequences. Yes, there are advanced type systems of that kind available -- Lisp is an extremely extensible language.
I'm not exactly sure what the point of universal lazy evaluation is, but you can do it in Lisp if you want to. Likewise, there's no particular reason why you can't curry functions automatically, but I'm not sure why you'd want to. Functions in lisp don't need to be curried because they can take more than one argument.
I agree with your comments on Pike...languages which don't compile themselves are so lame (*cough*Perl*cough*).
Haskell is a pretty cool language, but I wouldn't say it has "outclassed" Lisp. There aren't too many advocates of functional programming left nowadays...lets not belittle each other with petty in-fighting.
-W.W.
"Well it should be obvious to even the most dim-witted individual who holds an advanced degree in hyperbolic topology...
you didn't define a return type for your main () function. You will be shot. It _should_ be int and include a return (0);
not really true.
pike actually goes back to the late 80ties when lars pensjö first wrote lpc.
check the history of pike here.
if you are interrsted in the history of a language and want to enter the world of lpc read some paragraphs about lpc and lpmuds: history, what is lpc
what is an lpmud, lpc servers (the lpmud servers listed there are essentially lpc dialects)
(Profezzorn, mentioned here, is the author of pike)
another interresting introduction to lpc. :-)
(what is said here in 2.1 and 2.2 is essentially true for pike and roxen: just replace "lpc objects" with "roxen modules" and lpmud with roxen and most other occurances of lpc with pike
here the history to one of the lpc dialects.
go back even further and find out how lpc was started in the first place.
as you can see, pike has a very lively history and a lot of background.
greetings, eMBee.
--
Gnu is Not Unix / Linux Is Not UniX
As far as learning a new language goes, it's not that bad, really (it's far from being my "native tongue", so to speak). I find myself reverting to Perl when I want to knock something out quickly, but Pike is not so different as to slow me down all that much.
Please do not confuse conciseness with lack of information. Python does not support a basic programming notion that Perl does, one which is key for a well-known and powerful style of programming. That is a significant difference.
What more should I have said?
Regards,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
erm.. yeah he did...
greetings, eMBee.
--
Gnu is Not Unix / Linux Is Not UniX
Yo, bratha. We need a new language 'RAP'.
In addition, there is a plethora of interesting, powerful interpreters for languages that go beyond traditional scripting: EiC (ANSI C interpreter), CINT (C++ interpreter), Hugs/Haskell, CAML-Light, Scheme, Icon, CLisp/CommonLisp, Squeak/Smalltalk-80, etc.
Next time you feel the urge to invent a new scripting language, think about doing something genuinely new, rather than coming up with a language that is merely an incompatible, incremental improvement of something existing.
If you can't formulate some new idea that your language implements that isn't easily added to Python or Perl, I'd say, don't bother and work on one of the existing languages instead. Many of the existing languages need more libraries and better foreign function interfaces, and several of the existing languages would benefit from new implementations in C++ and/or Java, etc.
With my limited experience with and knowledge of pike I really don't see that it offers anything different. People went to c, c++, java, perl, because they fill a gap or offer a more elegant way to do something. Learning a language is easy, but mastering it is hard... why bother if the language really isn't different enough or truly necessary? This is why I've always had reservations about roxen as well.
Its good to learn and create, but why make something for which there really isn't a need. Python and perl are fine, why use pike?
Perhaps there is some specialty for which pike excels? If this is the case please reply and I'll take another look at it.
If you hook a user on Roxen or Pike, you can then point out that they can have it without the (check one or more) [_] expense [_] instability [_] insecurity [_] licence issues [_] embarrassment [_] opacity of running it under Windows. Odd it is that something named Windows opaque should be.
Got time? Spend some of it coding or testing
If you define "functional" as useful, rather than the more esoteric AI term, LISP does seem to be functional. It passes the FSF test of being able to send mail. Someone's even written a window manager in which all of the config and fanciness is LISP.
Yes, you can also do this in PERL, but it's a constant discipline not to do it in write-only fashion.
Got time? Spend some of it coding or testing
Well, I know I'm in the tiny minority, but I use ML every day.
The universe does not need more C-like OO scripting languages! OO is far from being the Mecca of language concepts. There are vast worlds of unexplored programming paradigms that lead to much more expressive, beautiful, and useful programming languages. There's nothing fundamentally more difficult about these languages and paradigms (though there are fundamental reasons why they're better, sometimes), just a reluctance for the programming masses to try something new. Or perhaps Sun's clever marketing of Java. Or whatever.
It saddens me to find us caught up using out-dated ideas and getting excited over syntactic sugar, marketing buzzwords, and a "getting things done" (think: RAD=perl=VB) mentality. Hackers have a duty to advance the state of the art by embracing new technology, because the suits don't care. Do the world a favor and learn/develop a new *different* programming language today!
Or, it could be that people who find the indentation policy objectionable won't stay around long enough to write at least 50 lines of Python.
I personally take pains to indent my code in a consistent manner, but for me, consistent is anything but simplistic. For instance, I might just put a very short block (such as an if statement with a short 'then' clause) all on one line for economy of space. Also, I have very particular ways of wrapping long lines, and of aligning similar elements across many lines. It's all very consistent and clean. It's also possibly somewhat unique to me. At the very least, I need only pay attention to my rules and the rules of whatever team I'm on, and not the language author's.
In other words, I've become very accustomed to the idea that whitespace belongs to the programmer and not the programming language. I'm not ready to relinquish my control over whitespace now that I've moved away from languages (such as BASIC, FORTRAN, etc.) that wanted to control it for themselves.
Note: I have looked over Python's whitespace rules, and I find them mostly reasonable. Still, I object on principle.
--Joe--
Program Intellivision!
I actually use pike in a work environment, since we run Roxen as our webserver. In general, I've liked it, as well as its integration with roxen. Here are my few good and bad points about it
Nonetheless, I've liked it so far and most of my problems have been the lack of good documentation for Roxen, compared to problems with Pike itself. I'm not really the best to evaulate languges(give me some time though), but if you know c/c++, it's a good interpeted language to move too.
I was not belittling you. I belittled the your love for Lisp. There are many like you, who get introduced to Lisp, as THE functional programming language... I wish more schools taught modern languages, as opposed to outdated languages (*cough* Prolog *cough*).
Automatic currying of functions reduces the amount of parens needed, when using functions of one argument or N arguements. Lisp has a parens fetish that gets a little messy now and then. Its not to not have to use them as much, as Haskell allows.
"Referential transparency" does not exist when there are side effects. Referential transparency allows transparent threading of your application. Think about have your app automatically run on 4 CPUs, without any code rewriting. Referential transparency also allows more simplistic proof of the properties of your code.
Please hook me up with some good resources on advanced Lisp type systems. Last time I checked, standard Lisp had no type system. A horrid weakness.
Universal lazy evaluation means that your data structures and functions are evaluated in a lazy manner. If you do not understand what I mean by that, then there is no way you can truely experience the beauty of modern functional programming. I know that Lisp may have lazy lists, but I know that overall, it has strict evaluation over its functions/data structures. Here is an example:
f x y = x + 10
Lazy evaluation:
] f (sqroot 2349 + 7/346) (sqroot 343568 + 7/346)
~ (sqroot 2349 + 7/346) + 10
~ (48.4867...) + 10
~ "After this point, the remainding expression is returned. If it needs to be evaluated furthur, because a function needs a more reduced form, then it is automatically reduced. However, it will only be reduced furthur, it is needed."
Strict evaluation (like Lisp, but using Haskell syntax):
] f (sqroot 2349 + 7/346) (sqroot 343568 + 7/346)
~ f (48.4867...) (586.1669...)
~ (48.4867...) + 10
~ 58.4867...
Notice how strict evaluation does more work than is needed? Sure, my example is trivial and silly, but there are cases, where it is not as trivial. Lets say I wanted to define functions over a boolean data type:
And True y = y
And False y = False
Lazy example evaluation:
] And (Not False) (And (Not True) (And True False))
~ And True (And (Not True) (And True False))
~ (And (Not True) (And True False))
Strict (ala Lisp):
] And (Not False) (And (Not True) (And True False))
~ And (Not False) (And False (And True False))
~ And (Not False) (And False False)
~ And (Not False) False
~ And True False
~ False
Note how strict evaluation continuously evaluates the second argument of And, even when it is not needed (the first arguement was False). If real life applications, Lazy evaluation allows for greater modularity in application design. Here is a paper, for you to read, if you care to furthur your knowledge of functional programming and the great benefits of lazy eval: Why FP Matters
I am sorry, but you have to learn why Lisp has been outclassed to understand. Its hard to just show people with a few examples. The paper I linked should be a good start. Many of the parts of Lisp that have been outclassed, cannot just be added on to Lisp. They are fundamental changes that would have to take place, to modernize Lisp. It would no longer be Lisp at all.
Also, read this entire book (its good, trust me): Good FP Book
I argue with you because you show potential. I won't even bother to discuss FP with most of the other people on this board. Many of them truely thing that Perl is a really good language. Its not even worth trying to argue with someone that burried.
GREAT links, moderate that one up! Thank you!!!! Ignorance cured.
How many languages that do relatively the same thing do we need???
-S
http://students.washington.edu/steve0/
steve0@u.washington.edu
- - - - - - - -
Don't worry, being eaten by a crocodile is just like going to sleep in a giant blender.
There once was a programmer named Mike
"An new language, yeah that's what I'd like"
He searched high and low
But it was Slashdot, you know
Where he first found a URL to Pike.
What's that? Not a haiku?
as from my past years experience with Java & Pike (or even LPC), I feel that Pike though not as clean as Java, it has its advantages of being flexible and handy:
Pike certainly has its disadvantage of being less well known, and less supported compared to the SUN & IBM boosted Java, but Pike has a much better license though. Pike's byte-code interpretor is solid but still pales when compared with those new JIT compilers for Java. It still has a long way to go in order to become a main stream language, or will it ever?
What the heck, as long as it fits my need and serves its purpose greatly, I am satisfied.
SecurityFocus' webserver is Roxen. A bunch of our webforms are combinations of RXML, pike and a few other things. I also had never heard of Pike or Roxen until I started here, and Elias forced me to learn it.
Anyway, my point is that I had to try to learn Pike by reading said documentation. It's really not very good. It's well organized, but it's incomplete, and lacks good examples. In many cases, I had to make inferences about how something worked by trying it and watching the errors.
The docs especially fall down when it come to how Pike works (differently) when called from Roxen via the tag. For example, I think it took me about 5 hours of searching the docs, mailing list archives, and other code already on our site to figure out how to get variables between the RXML scope and the scope.
Not that it's all bad, of course. There are some real nice features in RXML/Pike when it comes to forms processing, database hooks, etc.. variables submitted via forms appear in RXML code like first-class variables.
Self rules. Too bad you posted AC, otherwise I'd let you in on my two dirty little secrets: implementations of classless OOP (a la Self) for Perl and Python, complete with robust persistence, including code storage. I guess you'll just have to wait for the release :)
I am interested. I will have to read that paper you linked to when I boot into my GNU/Linux partition (with a postscript viewer).
"I argue with you because you show potential. I won't even bother to discuss FP with most of the other people on this board. Many of them truely thing that Perl is a really good language. Its not even worth trying to argue with someone that burried."
I can understand your point of view, amongst much of the language zealotry. But I hope you can still share your thoughts. What intrigued me was the following:
""Referential transparency" does not exist when there are side effects. Referential transparency allows transparent threading of your application. Think about have your app automatically run on 4 CPUs, without any code rewriting. Referential transparency also allows more simplistic proof of the properties of your code."
Are there any papers you can reference about this?
PHP 4 has support for Roxen, so if you like Roxen and not want to move to Pike, you might be interested in it.
-- Si hoc legere scis nimium eruditionis habes.
You need PHP for the list to be full :)
-- Si hoc legere scis nimium eruditionis habes.
From the perspective of a sysadmin, the roxen/pike combo leave lots to be desired. I was recently working for a company that did its entire web hosting business with pike and roxen, and I was not impressed with the stability of the roxen web server. The roxen process apparently dies at odd intervals (much like older versions of CERN httpd), and so requires a 'start' script to be running in order to restart it when this happens.
Another big complaint is the fact that there is no mod_perl equivalent for roxen. At the company I was working for, we had several users who ran their own perl programs, and because roxen could not instantiate a perl vm (like apache does with mod_perl) it had to start a perl process to execute that program. For those of you who did lots of perl stuff before mod_perl came along, you know how bad this is.
But the argument from the roxen/pike advocates is to tell people to write their code in pike. But it's not that simple. Some people have perl scripts that work just fine...why should they have to convert them?
I've also had some experience with the way pike handles regular expressions. Perl's RE engine is *much* faster than pike's. If you're doing text processing or pattern recognition, Perl is the way to go.
I suppose I've gotten spoiled with not having to declare variables in Perl...if you need a variable, you just declare it right there. Not so in pike. It requires explicit declarations at the beginning of the function (be it main, or whatever). Java forces you to do this also, but at least it allows you to declare the variables wherever you need to.
All in all, I'm still not sold on the combo. My current employer uses apache/mod_perl and perl with some in-house apache modules written in C, all running on linux. I have not seen a more stable setup. It just works.
Perhaps pike and roxen will mature and be a viable solution in the near term. But I would not stake a business on a non-mainstream technology. The simple reason for this is that there aren't very many people to answer your questions. But pike is fun to play with, and roxen does some really neat things....things that could be integrated into apache with modules, but just haven't been yet.
Enough of my rambling. Did I mention this is my FIRST POST?
mp3.com - s/revolt/revolution/g
The major problems that happen with multi-threading are largely due to the potential for unexpected interactions. If it is easy to show that there are no undocumented side-effects of a given piece of code, then it is far easier for an optimizer to move around when and where it is executed.
If there are potential side-effects then it can't do that unless it can prove that the side-effects in point A don't have any interaction (intended or unintended) with side-effects in point B.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
I don't remember where I read it, but someone once described AI as "everything we haven't yet gotten a computer to do". Theorem proving isn't AI anymore, because a computer can do it. Similarly, pattern recognition, chess, and natural language queries aren't really considered part of AI anymore.
Sort of sad for the AI people, though, since any progress they make is immediately removed from their domain of research.
As somebody who learned Haskell first and fell in
/ curry/).
love with it from first view, I nevertheless find
myself rather using Common Lisp for rapid
prototyping. You can just program so much dirtier
(setf, print, etc.).
Also don't underestimate Prolog. You might want
to check out the Ciao Prolog system
(http://www.clip.dia.fi.upm.es/Software/Ciao/).
It is good for some surprises.
Finally Haskell is not the end of it all, too.
Take a look at Curry, a Haskell-like language
incorporating the functional AND the logic
programming paradigm
(http://www-i2.informatik.rwth-aachen.de/~hanus
-- NoWonder of WonderWorks/OmegaProject
Please check the validity of your statements.
The roxen process apparently dies at odd intervals
Not anymore, the Roxen team has made a great effort to get things stable.
there is no mod_perl equivalent for roxen
There is now, and inline PHP and Java for the Roxen server. Hopefully the feature will surpass Apache stupid limitations on how many perl-modules you can have (I have not tried the thing yet...).
It requires explicit declarations at the beginning of the function
NO it does not! Check the documentation again. You can declare and re-declare variables anywhere and initialize them with any construct!
I often find myself asking people on the street about programming multithreading. I must *really* be dumb because the stupidity of my question causes blank stares.
Probably because I am an American.
:)
THese jokers saying Haiku is limited to these silly rules of syllables and such? English teachers in elementry school tried to teach us this 'way'. Haiku expresses a thought; that's all. With economy. 575, I hope you don't mind my repeating some of yours. Rythym and lingering content; light, pleasent taste.
Thank you
Pike is close to java in that they are both follow C syntax somewhat, extending it to OO concepts.
/* constructor */
It is unlike java in that while Java is strongly typed and you have to use typecast, Pike is as strongly-typed as you wish. You can use the mixed type to completely defeat any typechecking, or you can use classes and call them by name to be as strongly-typed as you wish.
Also notice that pike's concept of "class compatibility" is somewhat different from all other strongly typed OO languages, as it doesn't call into play inheritance. If two classes have similar signatures (names and types of public methods and variables), they are compatible.
Another novel approach Pike has is to function and operator overloading.
With C++ (and Java, if I remember correctly), overloading is defined by having different functions take different numbers and types of arguments: i.e.
void foo (int arg);
void foo (char* arg);
They are distinguishable at compile-time because the function signature is extended to its arguments' types, usually via name mangling.
Pike insteads allows arguments to be of different types. The above example would translate to:
void foo (int|string arg).
The programmer can then use runtime type information to discriminate.
Pike has both refcounting and garbage collection. It is quite uncommon to see the gc in action, as it will kick in when some percentage (I think half) of the object references are deemed garbage (it uses some adaptive algorithm to determine when to run). Or when explicitly invoked.
About static typing, see above. It can be as strict (or as lax) as the programmer wishes. It is refreshing to have some "mixed tmp" variable in a function and use it for loops etc.
About control flow structures, it has some more than C (i.e. foreach()).
The preprocessor if used wisely can be a nice weapon. For instance, you can detect the interpreter's version and use threads when possible. Of course, this also means that it allows people to write messy code. But they'd do it anyways...
It can be as dynamic as you wish. For instance, setting a method of another object can be done using a "function"-type variable:
class foo {
private int foo_bar() {
werror "foo";
}
function bar=_bar;
}
class gazonk {
private int gazonk_bar() {
werror "gazonk";
}
object foo_object=foo();
void create() {
foo_object->bar=gazonk_bar;
}
}
I could have also used anonymous functions (lambda) here.
i.e.
function foo_bar=lambda() {werror "foo";}
A nice thing about the language is that it doesn't try to hide details from the user. It is known what is handled by reference (every composite type, classes, objects, functions) and what is by value (basic types). It allows runtime inspection (via the indices, and typeof operators), remote objects, etc.
Since functions are primary objects, the whole runtime library follows a very consistent callbacks-based approach. This comes very handy when doing asynchronous I/O (one of Pike's strong points) or GTK programming.
About its "product placement" in terms of heavy-ness. It has some at-large programming helpers (more than TCL), and its syntax is less shell-ish than TCL's. Perl is IMO simpler for very simple tasks, but heavier for more complex ones (especially when need to go further than the string-array-hash types, and references come into play. Pike is much easier in this respect).
Python, I don't know really.I've never used it. I suspect that Pike and Python play roughly in the same league, neither clearly besting the other. I find Pike very convenient in I/O-related task, X programming (although here TCL/TK is better), and some simple text-manipulation tasks, requiring little text manipulation and a bit of variables-juggling.
About the runtime environment, Pike offers a two-pass compiler (no forward declarations), a mixed static+dynamic names binding model (intra-object references are static, inter-object they are dynamic), and a nice (but not comparable to CPAN) runtime library, including some nice DB-connectivity options.
If you want a real OO scripting language, pick Ruby www.ruby-lang.org, avoid C-like pike.
Well, at least that much is cool. And yes, I was aware of it, but only recently.
Now if there were only a way to tell vi how to "indent block" and "unindent block" when the language lacks explicit block delimiters, then perhaps I'd be happier about it. (I'm a heavy user of the vi key sequences >% and <% to indent and unindent blocks.)
I'll stop careening offtopic now. :-)
--Joe--
Program Intellivision!
What you say may all be true, but it still has Lots of Irritating Silly Parantheses.
In other words, it tends to be harder to read (and write) than say Java.
Female Prison Rape in NY
My current favorite is the functional paradigm as seen in ML and Haskell and OCaml. Lots of people find this bizarre, but after a little practice (took me about a semester and a half -- I hated it at first) I can hardly bear to use anything else. For a little evangelism from Bell Labs (including some of ML's other unprecedented features), check out:
m l
http://cm.bell-labs.com/cm/cs/what/smlnj/sml.ht
Actually, last year I did my final project for computer graphics (a ray tracer) functionally in ML. It was pretty slow (mainly due to vector bounds checking -- so it would be slow in Java too, for instance), but it wasn't really that hard to do.
Another reply to this message lists some other interesting (slightly more obscure) ideas that could wind up in languages of the future.
...
Will I retire or break 10K?
Well, do you often see comments that generate over 50 responses?
You can't handle the truth.
ObPike: what's it got that python hasn't got?
Will I retire or break 10K?
Touche'. :-) I wish I could give you a moderation point for funny, even if I had to steal one from my own posting.
--
--
Don't like it? Respond with words, not karma.
The above is misleading in that in uses the Blackdown JDK as opposed to one of the optimized IBM JDKs.
Does Lisp have referential transparency? Yes, of course, if you abstain from using side effects.
Does Lisp allow side effects and sequenced statements? Yes, of course, if you are willing to give up referential transparency.
Does Lisp have strict typing? No, it doesn't. On the other hand, Haskell does not have dynamic typing or does it?
Does it have universal lazy evaluation? No, of course not. If you need lazy evaluation, you can use it. If you don't, don't.
Does it automatically curry functions? No, it doesn't. If you need it, do it yourself. Currying is also not easy when you have advanced lambda list features like keyword and optional arguments.
Plus, Lisp has a feature I haven't seen in any other language: The defmacro facility. It practically allows one to invent a new language for the problem at hand. This is something that no Lisp-bashers seem to even acknowledge. I wonder why...
Lisp is not a language that forces you to do something in one an only one way. If you want to program imperatively, do it. If you want functional programming, you can do that also. Use lazy evaluation if you need it, not because you have to.
bye
schani
Seriously, closures are a very specific notion. If you have not seen them it will take you a while to understand what they are, and longer to see why people want them.
Why not start with some documenta tion? I have neither the ability nor the desire to fully explain an entire philosophy of programming in a brief post. Go and read a FAQ if you want to start down that path.
If this seems needlessly arrogant, ask yourself a question. If you wanted to make a comment on the calculus in a forum where some are mathematicians and some are high-school students, would you feel it sufficient to mention that your comment only will make sense to people who understand calculus? This situation is exactly parallel to that.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
First I think that few people who didn't already know what closures are could make heads or tails of your description. Certainly the concept of having multiple functions out there returned from the same one, each with independent data takes getting used to. The related idea of having multiple functions, each sharing specified data while not sharing other data is even more complex.
As for OO vs closures - that is really a question of philosophy. An OO philosophy encourages a particular structure on your code where all of your configuration information winds up scattered across your various class definitions. But in real life often you want to have some of that per class configuration information hidden away, but you would like to centralize other parts of it.
For instance when you are dealing with reports, the per field definition of where that field is coming from, what data validity checks you have on it, etc is all stuff that really should be centralized. OTOH per field information about how its display should be formatted, what column headings to use, etc is stuff that you want to centralize, periodically reorganize, etc.
I personally find that a functional approach lends itself more naturally for me to choosing to centralize display information into a single nested data structure. Yes, there are OO patterns to do the same thing. They look very ugly to me. For me having that choice is a win. But explaining that is more than a question about length of code. It is a philosophical comment
I have a friend who migrated from Perl to Python back when Python was able to treat regular expressions as first class objects and Perl did not. (It does now.) He commented to me a while ago that Python people claimed that anything you could do with closures you could do just as well without them in Python. He doesn't quite agree. Here are his thoughts.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
I have been enoying the ease of use with Roxen since 1996 or so... It has come a LONG LONG way since then... I think the 'coolest' thing about the web server was how it handled shell type scripts as CGI... pipeing a traceroute to the output for a web page actually resulted in roxen holding open the HTTP connection and 'streaming' the output to the browser, as opposed to apache, which buffered the output and then sent it as a page update...
People thought it was the coolest hack they had ever seen! (and they all though I was doing something cool with CGI baahahaha)
As usuall, we get some people who will automaticly slam anything that they don't know much about. So be it. Your opinion will be logged as being worthless, and your reputation for lacking intellectal honesty will haunt you forever...
And also TCL, just to be fair (even though I like Python better). :-)
Theorem proving in most cases has never been a part of AI research. It is possible to implement a theorem prover using AI principles, but most real theorem provers work through applied a rigerously developed formal system, which is very much unlike how a human generally tries to solve the same sorts of problems.
Haskell certainly does support data tagging ("dynamic typing"), but you're not forced to use this feature. There's no way to statically check lisp programs for type safety or to avoid runtime type-checks.
The defmacro facility can be simulated pretty easily in Haskell because of lazy evaluation. If you're an ML fan (like myself) and use strict evaluation, all the functionality you'd need here can be simulated (a little bit less prettily, but then again you don't have all those parentheses!) with infix operators and suspended computations.
One other serious shortcoming of lisp (that's even in such underachieving little brothers as Java) is the inability to hide the representation of data structures. Ouch.
I wont treat lisp as heavy-handedly as our friend here does, but it really isn't as advanced as the two most popular functional languages Haskell and ML. Mainly this is because of its extremely simplistic (elegant, maybe) type system. It's a great historical piece and even occasionally useful today as a scripting language (viz: emacs), but it's not the language of the future.
A type system allows your code to be statically checked for consistency. The links you've given us are lisp references. Lisp just has two types: atoms and cons cells.
Ever get an "undefined" variable at *run time* with a lisp program? That kind of nonsense doesn't happen with modern programming languages, and that's because of their type system.
Still without Lisp how would we customize our Emacs?
Steve
---
One nice thing about Pike is that its based on LPC, which if any of you are LPMudders, can be a good thing. A lot of us wasted a lot of our college (and post college) years programming in LPC ... and then to suddenly have that skill turn into something useful. Whoooiie!
Fooled me!
/. is, yes it is a forum with many people of different backgrounds. Like it or not, sometimes someone will have a point to make and that point will make no sense to people who do not understand a lot of concepts like "closure", "lexical scope", and "functional programming". There are lots of people who understand all that, and lots who do not. So I specifically said that my comment was one that would only make sense to people who had been exposed to functional programming.
First of all when I say "basic programming notion" I mean in general. Not for one language or another, but rather a notion that will come up in many languages.
It doesn't happen in C. It does in JavaScript. It doesn't in Java. It does in Smalltalk. It doesn't in Python. It does in Perl. It doesn't in VB. It does in Lisp.
Perl is specifically designed to allow "baby-talk". This is considered a feature. So you can program in Perl without knowing what a closure is. But if you don't know what a closure is, you won't know what lexical scope is. If you don't understand the difference between lexical and dynamic scope then you won't understand what the different between my and local is. If you don't understand that difference then you won't understand why Perl gurus keep on telling people to use my instead of local, and why use strict encourages people very strongly to do that. And if you don't understand that, then you will suffer needless pain from time to time.
As for what
Regards,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Whitespace;What->is($this{whitespace})@f_which||qr /youspeak?/;
- undoware.ca
"bad" from wasted words follow syntax 'til you bleed sweet strong blind rushing
Pike tries very hard to be C, too hard in my humble opinion. Programming languages are tools -- they should be useful instead of trying to imitate popular programming languages. Why not use C instead?
To all of you who have downloaded Pike I would just like to point out that you can email me at hubbe@hubbe.net if you have questions, or you can speak with me interactively at the roxen developers chat, which can be found on the Roxen community website. Happy hacking.
That's exactly what a closure is -- you use a function "m" which is dynamically bound to some kind of environment. Whether that environment happens to be an object, or just some variables which have been conveniently defined in the code lines surrounding your function doesn't really matter.
Perl just is damn convenient in that it lets you use both concepts equally easily. With Python you need to go the object-ish way when your program's logic becomes sufficiently complex.
NB, the Perl way to code up the above m is
$m = sub { $obj->method(@_); }
...
$m->(args...)
which arguably doesn't look as nice as the Python way, but (IMHO) that's a feature because I see better what's really happening.
He's a Bud man, eh?
In that case, I must proclaim
to the guy: "WAZZZZUUUUUUUUP!"
No boom today. Boom tomorrow. Always boom tomorrow. BOOM!