/prague/ Q&A

Ask /prog/ anything.

Although don't expect an answer or even a good one.

Also, keep it /prog/ related.

What is the velocity of an unladen swallow?

Estimating the Airspeed Velocity of an Unladen Swallow
Although 47 of the 74 worldwide swallow species are found in Africa, 1 only two species are named after the continent: the West African Swallow (Hirundo domicella) and the South African Swallow (Hirundo spilodera), also known as the South African Cave Swallow.
style.org/unladenswallow/ More from style.org

What is /prog/'s general opinion on Dijkstra?

>>4
Lucky sonofabitch who attached his name to an algorithm learned by every first-year CS student. Founder (unintentional?) of a programming style cult that is severely overrated.

Also smarter than /prog/ will ever be, and with enough accomplishments that our opinion is completely irrelevant .

Why is pascal not suitable for systems programming?
What's the key differences with Algol 60 and 68?
Why was Cobol so popular for data processing applications?

>>6

Why is pascal not suitable for systems programming?

The main/"canonical" Pascal dialect is unsuitable because it's (deliberately) crippled by quirks like forcing all code to be in the same file. It's a teaching language. There are other dialects that "fix" some of these problems but there's no point when they end up having no advantage over C whatsoever.

What's the key differences with Algol 60 and 68?

Algol 60 was kind of a crazy research project where they just threw a bunch of ideas together and tried to invent a new language. It's an overengineered, underspecified mess. Different compilers had different interpretations of the lexical syntax alone.

Algol 68 tried to put the smack down on that kind of nonsense and bring everything under control. In the process it discarded some of the fun features of Algol 60.

Why was Cobol so popular for data processing applications?

There are two reasons, and the first is the same as with Java: It was marketed harder than the alternatives and got an early foothold. The second is that it was sort of the Perl of its day. For a language invented when malloc() wasn't a thing yet, it's surprisingly good at taking strings apart and splicing them back together.

>>5
this
i've got fucking C because faggot landwhale CS examiner did not believe that i devised this trivial algorithm all by myself and therefore was unavare of its ``real'' name. what a bunch of faggots. half a year later i've left to physics department, have never regret this decision.

Why do some of you insist that SGML is better than HTML? It's the same load of horse shit.

>>9
Who the fuck says that and isn't obviously trolling?

why aren't you using lisp?

What's your major?

If NEET, what would you spend 4 years of your life studying from home?

Why do i see a lot oc go shit on hacker news? Why the hype? What advantages does it have versus other xoncurrent programmig languages?

>>12
Math because I hate it less than everything else.

CS because I need to eat, and companies get uneasy when all you have on your resume is ``ABSTRACT BULLSHITE (and Matlab)''.

>>13
I don't go on HN because it made me me literally ill when I did ^*, but Go is
- From Google
- Designed to replace that icky, icky C language thingy that is, like, soooooo 1970s.
- In its early days, so desperate to get a standard library that all you had to do to get your code merged was show up with a file that compiled. This lead to a bunch of people feeling like they were important in the Golang Community, which is a really good way to get vocal people to write blog posts upon blog posts about `vision' and `revolution' and `paradigm'. (It also leads to code quality which leaves something to be desired, as a few people later found out.)

^{*Well, it was probably the sandwich I had for lunch, but I say it was HN anyway.}

>>13
Asking why a language is good is like asking why a person is good. You can't really say someone is a bad person just because they're not successful or whatever. They have circumstances you don't know about and you're not going to get their whole life story out of them just so you can judge them for it. So maybe someone has a good heart but he's led an utterly shitty life through no fault of his own, and he ends up homeless and having to steal to eat.

When evaluating Go strictly on its merits as a language, I can't compare it favorably to much of anything invented after 1990¹. But let's pretend for a moment that all languages are equal in the eyes of the person actually writing the program: Go is no better or worse than Common Lisp, which is no better or worse than C, which is no better or worse than Ruby, and so on.

Now instead of comparing the languages themselves, we have to look at things like the release cycles of their major implementations, the change in documentation quality over time, the command hierarchy of their development teams, and all sorts of shit you wouldn't ordinarily include in your knowledge of the language itself. And in this sort of evaluation, Go is cast in a favorable light: It has a high-quality, open source implementation backed by literally one of the largest corporations in the world. It runs natively on a whole bunch of platforms without weird changes in behavior from one to the next (like Haxe has). The compiler runs quickly, producing fast binaries, and when errors occur it explains them pretty well. The documentation is downright bountiful. The community is very large, and a hell of a lot friendlier than the Ruby and Java clubs.

Go is the hedonistic, unambitious college dropout who never misses a day of work, never shows up late, and is always clean and sober and prepared to do the job. It doesn't claim to be a genius. It doesn't have to be. There is demand for someone who will move boxes around without breaking shit, and it fills that demand. That's all.

_{1. At least in terms of languages that are well-known enough to earn their complaints. Other stuff like X# (https://code.google.com/p/xsharp/) is obviously, and indefensibly, worse than Go. But nobody uses those anyway so you don't care about them.}

Are linked lists really bad?

Quick question. In C, if I declare a pointer

int *var

What's the differences between *var, var and &var?

>>17
Pretty bad, yeah, at least if you have any kind of performance concern.

The problem is that they're wasteful. Let's say you have a hundred elements and you want to iterate over all of them. The processor tries to access the first element, loads it into the cache, and does a thing, maybe some quick arithmetic. We'll just agree not to worry about the time cost up to this point, because it's the same for both an array and a list.

So the CPU finishes doing the thing, and now it needs the second element. With an array, the second element is already in the cache, but with a list, it's somewhere else in the heap, and chances are low that it happens to be in the same cache line (which is probably only 64 bytes long). So right away, with the list implementation, you have a cache miss and you need to fetch from main memory. Meanwhile the array version just keeps plugging away on the subsequent elements. In the time it takes for the list program to retrieve element 2, the array program could be ready to look for element 4 or 8 or 16.

This effect is compounded over the length of the collection. In the worst case scenario, the list-based code needs to go all the way to main memory for every element, whereas the elements of an array are guaranteed to be lined up one after another. You probably won't see it get this bad in real code unless your collections are extraordinarily long, like for example in scientific computing applications. Usually you have bigger fish to fry, like disk or network access. And in the event that your elements are large data structures, you can't really do anything without blowing out multiple cache lines, so it no longer matters how you've organized them. At any rate, linked lists are a code smell for a cache-aware programmer, especially a list of boxed elements, which is almost always the case in dynamically typed languages.

Memory consumption is a little more obvious. A 64-bit pointer is 8 bytes. If your elements are one byte each (like a UTF-8 character sequence) and your processor expects everything to be word-aligned, each list element consumes 16 bytes plus whatever the allocator uses for bookkeeping. A hundred-element char list eats up 1600 bytes. A hundred-element char array uses 101 bytes (if you're using end markers instead of a length counter). Try writing a text editor with a linked list as your main data structure, and see what happens when it reads its own source code.

Now, it's possible to expose linked lists as an abstraction for the sake of pattern matching, and then when you actually compile the program, you instead generate tight inner loops and array manipulation code. That's how it ought to work. Haskell, to its credit, does this some of the time. However, I get the feeling the actual optimizations involved aren't low-level to make it totally pervasive, which is a weakness that needs to be addressed.

I'm not aware of any Lisp capable of such optimizations.

>>18


int var = 420;
int *pointertovar = *var;
int **pointertopointertovar = **var (== *pointertovar);
int varaddress = &var;
int pointertovaraddress = &pointertovar;

I don't feel like explaining, better read that K&R

>>18
typeof(*var) is int.

typeof(var) is int * (the address of an int value).

typeof(&var) is int ** (the address of a pointer which in turn contains the address of an int value).

>>20
>>21
I see, so why doesn't this function work? First, I passed the Record * that I declared in main() to a function named input(Record *Something) so that I can ask for some data and call insert(). Whenever I try to print the data, the Record * I declared first in main() only seems to refer to NULL

int insert(Record *Phonebook, char * lname, char * fname, char * mobile)
{
/*
RETURN 0 IF SUCCESSFUL.
*/
Record *New, *Temp;

New = (Record *) malloc(sizeof (Record));

/* If malloc returns a null pointer... */
if (!New) {
return 1;
}

New->lastname = (char *) malloc(strlen(lname) + 1);
strcpy(New->lastname, lname);
printf("%s", New->lastname);
New->firstname = (char *) malloc(strlen(fname) + 1);
strcpy(New->firstname, fname);
New->mobilenum = (char *) malloc(strlen(mobile) + 1);
strcpy(New->lastname, mobile);
New->Next = NULL;

if (Phonebook == NULL) {
Phonebook = New;
} else {
Temp = Phonebook;
while (Temp->Next != NULL) {
Temp = Temp->Next;
}
Temp->Next = New;
}

return 0;
}
Did I fuck up the scoping and deleted the *Phonebook in input() when it ended?

>>22

Did I fuck up the scoping and deleted the *Phonebook in input() when it ended?

First of all, you've got a poor understanding of C's manual memory management. You lost the address of the new Record you allocated, but it's still on the heap taking up space. That's a memory leak. Someone's gonna point that out and it might as well be me.

And second, yeah, you'll want to change Phonebook to a Record **, and rewrite that last section as follows:

if (Phonebook != NULL) {
if (*Phonebook == NULL) {
*Phonebook = New;
} else {
Temp = *Phonebook;
// ...
}
} else {
// Signal an error and/or deallocate New
}

>>19
How do you feel about cdr coding and GC-time list compaction?

For reasonable things like parsing config files or setting up a firewall or implementing a text editor that is; if a programmer did any consing (unless it's the kind that gets optimized out) in any tight loop that gets executed for more than 0.01s I would not only fire them but also douse them with gasoline and set them on fire, for humanity's sake.

What's your favorite data structure /prog/? I like trees. They're so beautiful when they're symmetric.

>>23

Yes I have yet to make a delete function.

>>25
I like arrays, because they have low overhead and high speed^*, and can be used to implement many other data structures.

^{*Depends on the language, of course. But good array implementation is common.}

>>25
Hashes or Database schemas (B-trees?)

>>27
How is it even possible to fuck up an array implementation? Can you call anything that's not a contiguous chunk of memory an array?

>>24

How do you feel about cdr coding and GC-time list compaction?

As I said, I'm not against lists as an abstraction so long as the compiler (or library maintainer) can mitigate the costs with a sensible representation. I would prefer unrolled lists, of which CDR-coding is a specialization, in a way, and there are environments in which the latter makes more sense. For example, if you're already committed to working with tagged pointers, or if the list structure has to be mutated often (ugh). CDR-coding's small additional cost in CPU instructions is certainly preferable to cache misses, if it ever comes to that. There are architectures on which it's downright negligible.

GC-time list compaction is something I admit I've never heard of and can't seem to google right now. From the name it sounds like it would only work with memory models that run on handles instead of direct pointers. Could you tell me more about it, and perhaps point out some implementations?

>>30

From the name it sounds like it would only work with memory models that run on handles instead of direct pointers.

Depends. If you don't want a non-incremental ("stop-the-world") collector (and you almost never do except when implementation simplicity/size is the most important thing) then you will have to do tricky, nasty and possibly inefficient things to avoid using handles. Using handles instead of pointers at most doubles your cache misses, and you can cache pointer-handle associations in a per-thread structure so you don't waste cache on handle table entries that you won't use anyway.

Could you tell me more about it (...)

The GC has the `power' to lock structures, and it [i]has[/i] traverse them anyway (to mark things), so while it's doing its marking stuff it could also compact lists into unrolled lists as it goes through them and move them to a new location.

(...) and perhaps point out some implementations?

I am not aware of any, sorry. I am not familiar with many languages' implementations.

Q: how harmful is serialize using JSON in Berkley DB?

>>28
B-trees, of course. Don't they make your heart go doki-doki?

>>29
I dunno, man. Maybe in a toy language or something. Maybe it turns out that under the hood the JVM doesn't actually create arrays as contiguous, or some shit like that. If I'd said that low overhead+high speed was universal, somebody would probably have pointed out a language in which it isn't.

>>32
I'd say it depends highly on exactly what you're serializing, and who
you want to read it. If you're storing records of people with names,
birthdays, street addresses, and other good-for-homework collections
of data that mimic slightly mutable hashes themselves, and especially
if there's a possibility that in 10 years another programmer will want
to pull that data into another application, then JSON serializing is
probably not a bad choice. If you're using it to store something
that's already pretty specifically defined, like states of a
chessboard, just suck it up and use Huffman coding of the board state,
especially if you are expecting to run into size constraints.

In general though, I'd be cautious. JSON is, after all, representing
data fundamentally as a nebulous mapping, right? Since you're using
db, you've got a nebulous mapping system right there! And if your data
is tricky enough that you're trying to pass off the serialization
burden to another representation (assuming your application doesn't
pass around JSON blobs internally), it might be something like image
data, in that it can probably be serialized better a different way.

>>35
Thank you, now I'm more confident about using JSON: it seems to be the most scalable, portable, and fast option for what I'm trying to accomplish.

Serious post: Why Lisp? Why functional programming in our current computer technology? Why is there no SICP 3rd edition yet?

>>37
K&R is long due for a 3rd Edition. But I guess since Ritchie, is ded, even if Kernighan made a new edition, you can't call it K&R... ;_;

>>37
How can you not like Scheme after reading chapters 4 and 5 of SICP?

>>33
I wasn't asking.

>>36
Or SQLite for that matter. [spoiler]Wasn't it previously published here all the lightweight DB engines⸮[/spoiler]

>>37

Why Lisp?

not a correct question. Try "Why use Lisp?" on a search engine. We have answered this question xx times.

Why functional programming in our current computer technology?

Pffft hahahaha. https://encrypted.google.com/search?hl=en&q=current%20computer%20technology

About 273,000,000 results (0.32 seconds)

Why is there no SICP 3rd edition yet?

There's, and it's in FIoC. You are welcome to update your onw with R7RS &/| R2004.

et al.

Bet you creeps did not know about Common Lisp HyperSpec:
http://www.lispworks.com/documentation/common-lisp.html