A few years ago I got some books for free from a second-hand bookstore here in Zagreb, Croatia, where I live. One of those was a Real World OCaml book with a dedication from Jane Street Team to someone named Gustav. There were also some other books about functional programming given for free. I guess Gustav decided functional progamming wasn't for him, and just dumped those books to the first bookstore he could find.
Also, a few years back, I borrowed The Agebraist by Iain M. Banks from a local library and found his signature in there on the title page.
Just noticed that in Perl the behavior is slightly different: http://perldoc.perl.org/functions/fork.html unsuccessful fork() returns undef, effectively stopping you from kill-ing what you don't want to kill.
Similarly python throws an exception, and I bet other languages have their own behaviors, but in case of C this is the only way (or at least it is the only non complicated way to do it).
When I read this article I thought it was preaching to a choir. I'm actually quite surprised people programming C don't check for errors. That's the only way the functions can provide a feedback.
Nothing in C forces the API designer to use -1 as "bad PID" in one place and as "the set of all PIDs" in another, however. Perl's undef isn't that different from returning, gosh, -2 or any other bloody number except -1 in C.
fork() returns pid_t type which is usually mapped to int32_t. For this type there's no equivalent of Perl's "undef", the -1 is standardized as an error in all system calls that return an integer.
As for the argument why not send -2 instead, well guess what? Other negative values also have a meaning. Negative values in kill send signal to a process group instead of a process.
It's not libc responsibility to predict all possible things the programmer can do. Also unlike perl, C doesn't have exceptions so it can't exactly quickly terminate on error showing what went wrong.
Imagine C throwing SIGSEGV every single time a function failed.
> As for the argument why not send -2 instead, well guess what? Other negative values also have a meaning. Negative values in kill send signal to a process group instead of a process.
That's the problem there. Kill takes an argument that's either a process id or a magic number or a different magic number or.... Those should be different functions, and the special cases like "kill all processes", "kill all processes in this group",... should be some kind of enumeration type. But it's C, so...
Interestingly, the kill procedure in Perl explicitely checks for non-numbers, which is unusual. Perl as a language would just cast undef to zero in a numeric context[1], and 'kill $signal, 0' would go on killing every process in the process group.
$ perl -we 'kill 9, undef'
Can't kill a non-numeric process ID at -e line 1.
[1] unless you "use warnings FATAL => 'uninitialized';"
A null pointer does not need to have an all-zero representation, which mattered once on some architectures. I'm not aware of any current architecture that does it that way, but that's still what the standard says, which is to say that C does technically have a notion of null which is not necessarily identical with 0.
"For practical purposes, the null pointer and the integer `0` are one and same."
For most practical purposes, which is why I said that it wasn't a terrible approximation. However, they can be distinguished on some architectures:
intptr_t x = 0;
void *p = 0;
x == *(intptr_t*)(char*)&p;
I can easily construct fantasy scenarios (involving more than a bit of Doing It Wrong) where this would be relevant. I'm not convinced it couldn't ever be relevant without Doing It Wrong, if one in fact needed to work on that kind of a system.
> historically it's had a great user manual for beginners.
The quality of Postgres' documentation was the thing that was a big plus for me more than 10 years ago when I started fiddling with databases. MySQL came with one big 1MB+ HTML file, while Postgres had nicely organized multi-HTML docs. Even if you know nothing about databases, my vote goes to Postgres' docs for really good explanations of what to do, and what's going on. Of course, nowadays everything's easy with apt-get and stuff.
Great idea, but not for traffic conditions (all traffic signs have to be unambiguous all the time). Also, these small touchscreens in a public area will eventually be smashed or stolen.
(Disclaimer: I am a native croatian speaker.) There's a significant difference between croatian and serbian language: croatian language is composed of three dialects and a standard language which are not found in serbian. It was a political movement to merge one of those dialects (shtokavian) with serbian language. So, serbian is somewhat similar to shtokavian but not to other dialects that compose the rest of the croatian language.
I, as a native Serbian speaker, have a 100% understanding of what is being said on Croatian national TV, and 100% understanding when reading websites in Croatian.
While the difference exists, calling it significant is just... untrue. For non-speakers, it is barely noticeable.
I have probably the same understanding of serbian. I used to read a lot of science fiction literature translated into it. Not to mention that I learnt cyrillic script in elementary school in the 1980's when the language was still officially called "serbo-croatian".
But there are significant differences: for example serbian people don't understand kaykavian and refuse to. There are a lot of jokes on the theme in old yugoslavian tv shows. Kaykavian is part of croatian language.
I am not sure what you mean. I tried to explain the situation. "Serbo-croatian" as such doesn't exist (http://www.britannica.com/EBchecked/topic/535405/Serbo-Croat...). Yeah, you can mix both of them and speak serbo-croatian as a mixture of both, but people also mix english language with their mother tongues. How many kids today name their language as "croatian-english" or "german-bosnian" for example? And I heard both of these in real-life situations.
There's one obvious way to write good Perl code: read the documentation. Perl has tonnes of it. There are bugs in there of course, but most of it is very good. Also try to visit perlmonks.org once in a while - they're good there. Everything else is just a reason to be lazy and not care about the code you write.
And, Perl has an awesome community, let's not forget that. They do love clean code and all (modern Perl is very easy to read and understand IMHO), but are aware that in the end you want to get the job done.
Time and again, the question "are there any useful ideas or features in language X that we can borrow and implement in Perl?" has been posed by prominent people in the Perl community. Which is the opposite of the "not invented here" syndrome.
There's another obvious way to write good Perl thanks to the CPAN: don't write it because others already made the work better than you. @mutation: i agree with doc quality.
Well, the documentation system on CPAN is ancient and awful to use.
I have often enough found missing documentation. Particularly perl programmers seem to give a f*ck about documenting return values.
And even when there is a good documented function, often enough i am not smarter after reading.
Just picking a random method of a random module here:
What's the return value? Is there really no result? And what is cache? I can't even click that variable and see it's structure.
As a reminder, i just picked some random module. It's 2013 and not 1980. I'd like to know that kind of stuff quickly when i check for arguments and how to call stuff. I like that stuff in my editor/ide as well. Clickable. Call me lazy, but i do want to work efficiently and not trying to google all day for a simple usage example. I like to get the work done.
You're partially right about perlmonks. It's a great resource for perl! Sometimes it seems like it's the last stronghold of the perl community but it has great answers.
What is not so great is that i find multiple solution (like more then 10) for a very simple problem, but that's subjective..
I usualy use Tcl for my personal projects. It's nice and simple but powerful language, and the only real problem with it is that there's too many old libraries that can't work with multiple but different versions of Tcl on the same system.
Also, a few years back, I borrowed The Agebraist by Iain M. Banks from a local library and found his signature in there on the title page.