>>4
A shit excuse (all excuses are shit) used by faggots to excuse their shit software.
>b-but hardware advances! software doesn't have to have quality programming anymore!
typical fuckin atheist retards with no values
Name:
Anonymous2013-06-29 5:12
>>1
It's an implementation detail. Here is a poor example that should get the point across. SBCL 1.1.4 on AMD64 was used. CL-USER> (declaim (optimize (compilation-speed 0) (debug 0) (safety 0) (space 3) (speed 2)))
; No value
CL-USER> (defun int++ (x)
(declare (type fixnum x))
(the fixnum (+ 1 x)))
INT++
CL-USER> (compile 'int++)
INT++
NIL
NIL
CL-USER> (disassemble #'int++)
; disassembly for INT++
; 0421194F: 4883C202 ADD RDX, 2 ; no-arg-parsing entry point
; 53: 488BE5 MOV RSP, RBP
; 56: F8 CLC
; 57: 5D POP RBP
; 58: C3 RET
NIL
As you can see, the code is pretty compact. Not to mention inlining can be used at the cost of full dynamicity. The real reason that C code is smaller is that C code does less.
I have to admit though, some of the extra you get with high-level languages can't be removed. For instance, as you can see, the value's lowest bit is used for type tagging purposes.
>>3
vi and derivatives thereof are garbage. Use Emacs, even for C, for it puts most other text editors to shame.
>>4
Very delusional. Even if that were true, memory bandwidth is more of a bottleneck than ever.
Name:
Anonymous2013-06-29 5:32
This Cudder isn't the "US english and UK english VN" guy, its probably the "GC is shit" guy, or Gerald J Suss himself.
It's an implementation detail.
It's an "implementation detail" that means the difference between "small and fast" and "does it really take this much code to do $trivial_task?", or if you scale up, between "it works" and "we need to buy more hardware", so it bloody well matters.
Your example is useless as no one would ever write code like that in practice anyway. It's usually (needlessly) full of things like higher-order functions, which have much higher overheads. This reminds me of an old quote about Asm vs C, in response to the "you can write inefficient code in any language" argument: "Because of the amount of effort you need to expend to write any code in Asm, you will naturally be encouraged to use as few instructions as possible, resulting in much higher code density." Compare this to C++ where e.g. writing std::map<std::string,std::string> v; and calling several methods on it is enough to instantly generate a KB or more of code, or to take this to an extreme, eval in even higher level languages (like Lisp) is sufficient to add to your executable a substantial portion of the bloody compiler itself!
"With great power comes great responsibility." And I'm not sure if the majority of HLL programmers out there should have that responsibility.
No, OP is not me. Obviously.
Name:
Anonymous2013-06-29 10:28
I love Cudder.
I love C, I love LISP, and I love Jews.
Name:
62013-06-29 10:53
>>12 Your example is useless as no one would ever write code like that in practice anyway.
A C programmer would, and should if ey want to compare C and Lisp in an honest way.
"With great power comes great responsibility." And I'm not sure if the majority of HLL programmers out there should have that responsibility.
I doubt the programmers who cannot sparingly use powerful abstractions would be good low-level programmers.
eval in even higher level languages (like Lisp) is sufficient to add to your executable a substantial portion of the bloody compiler itself!
There is no such thing as an “executable” in the Lisp dream world, not in the usual sense at least.
Name:
Anonymous2013-06-29 16:57
>>12 $trivial_task
I hope ya not using PHP these days, Cudds, I expect no less than assembly web services from you.
It's usually (needlessly) full of things like higher-order functions, which have much higher overheads.
But higher order functions and objects, which are simply glorified structs, are identical. A lot of C code pass around structs. It just looks different syntax-wise.
eval in even higher level languages (like Lisp) is sufficient to add to your executable a substantial portion of the bloody compiler itself!
Thats the idea, its also a niche, though.
[b][u][i]
LET ME TELL YOU WHERE YOU CAN STUFF YOUR FUCKING LIBC BITCH
NOWHERE IN MY MEMORY MODEL, THAT'S FOR SURE
CAUSE THAT SHIT IS DEAD WOOD FOR C DIPSHIT
AIN'T GOT ROOM FOR THAT SHIT
GT*F*O [/b][/u][/i]
A C programmer would
No. int addone(int x)
{
return x + 1;
}
That's TDWTF material.
There is no such thing as an “executable” in the Lisp dream world, not in the usual sense at least.
And this is exactly what's wrong with Lisp and the entire cult surrounding the language: You mentally masturbate over theory, with little applications to practice, and is as useful to real programmers as a discussion of spherical cows is to a farmer.
I hope ya not using PHP these days
At least the majority of web hosts out there support PHP. Which is what it's good for, generating webpages. (And little else.)
But higher order functions and objects, which are simply glorified structs, are identical. A lot of C code pass around structs. It just looks different syntax-wise.
It's far more likely that the C code actually has a real need to use a struct, as opposed to the higher order function which may just be for shits and giggles. As I said above, it's not as easy to add a struct compared to a lambda in Lisp; and that at least causes programmers to pause and ask themselves "do I really need to be doing it like this". With Lisp, it's as easy as (lambda ...), and suddenly you've "written" a lot more code than you thought.
>>16
C++ is just a step above C in terms of making it easy to generate lots of code, whether you really need it or not.
>>19 majority of web hosts out there support PHP. Which is what it's good for, generating webpages. (And little else.)
(Ç_Ç), its sad seeing everything go to hell. When had perl to make the quick work, then reimplemented to low level C. It is sad those days are gone. orgmode.org has it at the least correct
Name:
Anonymous2013-06-30 8:45
I just want to say that C# has all the interesting features of lisp and (if you're not lazy) equals c in performance (on windows at least). Only the memory footprint is worse. It's also much faster to work with, a quality Lord Paul Graham espouses.
LOL @ ``Cudder'' by talking of higher order functions as if they were something fancy which must be used with responsibility and a frown on one's face. Map is the most natural thing to use in the world, but enjoy your for (_;_;_) {} loops forever.
>>21
No macros, not ``all the interesting features of lisp''. If having anonymous functions and curly return semicolons is all you need, then good for you.
>>21
I do not doubt it. But µ$ makes no contribution outside for other systems, not even to the Mono Project. Then again, Perl and POSIX is nearly everywhere, I can port my wml code on any machine, and replicate it elsewhere, being architecture and environment ignorant.
To be on topic, Lisp expressed that Turing Complete and abstract programs exist, and can be evaluated while executing: REPL. Something all other abstract languages depend on.
Now imagine a program that is responsible and self healing in a system for the amount of resources it uses. What produced out of LISP was just that, a Garbage Collector, protecting system failures/errors while ensuring execution.
Name:
Anonymous2013-06-30 10:06
>>28
Erlang is better at that. Nobody uses lishp except for some web-monkeys who use Clojure.
>>20
Another poor bastard with its head in the clouds... the reason PHP is so popular is because it's easy to lock down for a webhost that wants to isolate its users from each other. You can't do that easily with a general purpose language that can easily do a lot more; and for 99.999% of the time you use a webhost, you shouldn't be, and they don't want you to, do anything other than generate webpages.
higher order functions as if they were something fancy which must be used with responsibility
They are equivalent to a struct/class and a function pointer, and if you were using something like C/C++ you would not (or should not) indiscriminately create dozens of those.
Map is the most natural thing to use in the world, but enjoy your for (_;_;_) {} loops forever.
Loops are more explicit, easier to understand, and are always inline (like they should be; they have practically 0 overhead and calling a function that just loops, which is what a map is doing, is needless overcomplication.)
>>31
All he did was write an assembler for one of the simplest CPUs ever in Lisp, with syntax that's more verbose than standard Asm. Sorry, that's just FAIL.
Name:
Anonymous2013-07-01 6:56
>>45 PHP is so popular is because it's easy to lock down for a webhost that wants to isolate its users from each other.
But this is flat out false, safe_mode is deprecated for a reason: because they, as usual, had no clue what they were doing. What you are thinking of most likely is chroot, all languages can "do this correctly" because everything can be chrooted. Even the cheapest shared hosting plans of the cheapest hosts still support CGI like they did 15 years ago.
For the most flexible yet proper methods of isolation on the runtime level you can only consider languages with environment specified evals, like Lua and Schemes that implement it. A JavaScript process is a sandbox on its own, but it can't make sandboxes with eval that I'm aware of.
>>46 chroot
Not going to work on a server process that's serving multiple hosts.
Name:
Anonymous2013-07-01 7:10
>>45
How are loops more explicit and easier to understand than map? With map you see just what is done to each element, while with a loop you see needless machinery and boilerplate.
>>45
More explicit? Hilarious! You can contort the flow of control arbitrarily within any loop, whereas map, filter and fold will always do the same thing by themselves, and that's the point.
The rest of your comment gave me visions of epic works of copy+paste in the name of stack-frame preservation.
>>45,47
There something called Jails, and SE Linux groups, that isolates user processes regardless programming language of choice. Even then Perl was there with almost all things needed to create pages and daemons for most of the work, that can be automated. If you need to embed script you can, in any language. PHP just solved the problem with the massive competition, utterly fuck anything that has been made with it.
Heck, you can even make simple limited VMs to provide all the necessary components you need for a client. That is why projects like OpenStack are getting so much poularity.
Name:
Anonymous2013-07-01 19:24
>>45 with syntax that's more verbose than standard Asm. Sorry, that's just FAIL.
YOU HAVE FUQIN ANGERED AN EXPERT PROGRAMMER
the reason PHP is so popular is because it's easy to lock down for a webhost that wants to isolate its users from each other
What the hell are you talking about? How does PHP help to isolate users from each other? You seem to have PHP confused with a security-minded programming language. You must not have gotten the memo.
Also, PHP is popular because it was the first HTML template language with a programming language built in, at a time when Perl, the then de-facto language for web programming, didn't have any decent template libraries.
You obviously weren't programming in the 90s, so please stop trying to rewrite history like you were there or have any idea what was going on.
>>45 Loops are more explicit, easier to understand, and are always inline (like they should be; they have practically 0 overhead and calling a function that just loops, which is what a map is doing, is needless overcomplication.)
You must have never written, studied or even read about Lisp compilers. Have you heard of tail-call optimization? Do you know what that is? Do you know what it means? Do you know how it's implemented? Go ahead and write an infinite recursive loop in Scheme. Run it. Wait for it to run out of stack. I'll wait...
What's that? Still running? No overflow? Now if you're such an expert on machine architecture, please explain to me how TCO is possible if the interpreter keeps making function calls. The mapper function can be inlined too, especially if it's a lambda or compound procedure.
Why don't you try using a Lisp compiler and studying it's output before demonstrating to everybody here that you don't know what the fuck you're talking about.
Not every compiler is smart enough to make the right decision when inlining map calls. And you may need to make the loop explicit if you want to use it well with inline assembly.
Name:
Anonymous2013-07-02 3:42
spambegone
Name:
Anonymous2013-07-02 3:42
spambegone
Name:
Anonymous2013-07-02 3:42
spambegone
Name:
Anonymous2013-07-02 4:24
>>70
If the mapper function is a lambda or primitive, inlining is basically guaranteed. You'd have to make great effort to ensure that they're not compiled inline. Only inlining compound procedures takes any real effort and there are plenty of Lisp compilers mature enough to make that effort.
You can contort the flow of control arbitrarily within any loop, whereas map, filter and fold will always do the same thing by themselves, and that's the point.
So the point is to do more work than necessary, out of some pointless desire for "elegance" or something? With a loop, you can start and end at any point in the array, the points which actually need processing.
>>59
You can configure PHP with very fine control over what functions are allowed, the maximum amount of time and memory, etc. This has nothing to do with "web application security", as a host you usually don't care if your users' sites get hacked since that's their fault, but you don't want that to down the server for everyone else. How are you going to do things like disable backticks (makes it too easy to spawn additional processes) without recompiling Perl, not to mention parsing itself is Touring-complete so even an analyser that tries to parse the scripts and strip out disallowed features would not be guaranteed to terminate! Perl was designed as a "glue language" which is why these things are easy to do, and hard to manage when you don't want your users using them. The same issue applies to all the other general-purpose scripting languages that got used for generating web pages.
>>60
Some C and C++ compilers do TCO as well. You seem to be assuming that ALL calls are going to be tail ones, when the exact opposite is usually the case. You smug lisp weenies always bring up TCO like it's the ultimate solution to everything --- and in some ways it is, since the language requires it for any nontrivial code to work! But if you ask me, needing an optimisation for it to be possible to do anything useful with the language at all is a big FAIL.
"Lisp is like a loli imouto. Cute and fun to play with, but you wouldn't want to ask her to do any heavy lifting."
Name:
Anonymous2013-07-02 4:47
>>75
TCO in C/C++ has some challenges, while they aren't show stoppers. One complication is stack allocated memory. If you pass a pointer or reference to stack allocated memory when calling a function in a tail position, performing tail call optimization could crash the program, since using the pointer would then refer to stack used by the tail-called function.
int f()
{
int x;
return g(&x); // Not safe to tail call.
}
A C/C++ compiler needs to prove that TCO is safe first, which can become non-trivial or impossible, but is usually straight forward.
Most tail calls get compiled to simple jumps within a local body. The real deal tail calls that make debugging difficult and program control flow so difficult to follow are usually not much worse than a normal function call. There might be some shuffling on the stack. I guess my point is not to confuse functional style with the other features of lisp that make it more difficult to get high performance code, with that being garbage collection, dynamic typing, or the theme of interpretation.
>>76
That's easy. Just move x into g and take its address there. If its only having its address taken only to be dereferenced again (and no pointer arithmetic), then the compiler can even eliminate the indirection completely.
Name:
Anonymous2013-07-02 6:41
>>75 setuid to who? Certainly not root.
If you want to pass off as an expert, at least read up on what shared hosts actually do? I'll throw a bone: many hosts don't actually run PHP in-process for what is a server full of babby's first sites with no traffic. As far as CPU allotment goes from this setup, they just cut off and request the customer to upgrade on the few sites that actually get any traffic, as it is usually stated in their ToS.
You can configure PHP with very fine control over what functions are allowed, the maximum amount of time and memory, etc.
PHP is a thin wrapper over a bunch of cobbled together shit, it doesn't guarantee anything no matter what php.ini tells you. As far as I'm concerned the only real use of the time limit thing along with ignore_user_abort settings is to prevent the error log from filling the hard drive because of the combination of loops and PHP's shitty semantics that ends up creating unintended infinite loops.
usually don't care if your users' sites get hacked
Actually they do, depending on what they have for a setup, if it is an in-process setup compromised sites end up downloading payloads, which PHP happily obliges with its fopen wrappers, uses a vulnerability to hijack the server process and end up snickering at these silly time limits and memory limit stuff because now its just machine code with the web server's user id.
How are you going to do things like disable backticks (makes it too easy to spawn additional processes) without recompiling Perl
How is Cuddersoft Hosting solutions going to compete with 5$ hosts that provide CGI in their plan? As an example I just googled "hostgator perl" and theres a page on how to set it up on their shared plan. There's nothing here.
The same issue applies to all the other general-purpose scripting languages that got used for generating web pages.
Are you lumping Lua and Lisp's parseability with Perl as a reason to choose PHP?
Some C and C++ compilers do TCO as well.
That's nice, but how does that change anything? Writing C code that can only run because of the TCO in some random compiler would be sort of foolish. Whereas writing the same style in other languages where the language specification requires it basically makes the code properly conformant to the standard, runtime-wise.
But if you ask me, needing an optimisation for it to be possible to do anything useful with the language at all is a big FAIL.
How is it a fail that a language expresses a philosophy, actually follows it, and actually succeeds in its objective? You seem fixated on the word "optimization" and using it as a connotation, it is sometimes also called Tail Call Elimination, if that's more your fancy. This is very much like arguing that C is a big fail because it derives utility out of evaluation short circuiting on its boolean operators.
many hosts don't actually run PHP in-process
mod_php is far more common in my experience than anything else.
which PHP happily obliges with its fopen wrappers allow_url_fopen = 0
As an example I just googled "hostgator perl" and theres a page on how to set it up on their shared plan. There's nothing here.
I'm not saying there's no hosts out there that let you run CGI, but you're far more likely to get PHP support than anything else. Rather, try to find a host that has CGI but not PHP...
Are you lumping Lua and Lisp's parseability with Perl as a reason to choose PHP?
Are you illiterate? Did you just skip over this point, which is what the issue I'm referring to is about? "Perl was designed as a "glue language" which is why these things are easy to do, and hard to manage when you don't want your users using them."
How is it a fail that a language expresses a philosophy, actually follows it, and actually succeeds in its objective?
It has succeeded if its objective is to be as perverse as possible. Recursion via a function call is NOT the same as a loop, because that's not how real machines work. Just because some theorist with his head in the clouds (and possibly high on something) showed how they are in theory doesn't mean it's true in practice.
>>79
WOW! Cudder just shown deep knowledge on PHP and the nuances of web-development.
I think Cudder is really a creative transgender woman working in designing webpages, while C++/x86 faggory is just a hobby for "her".
Name:
Anonymous2013-07-02 11:59
>>81
"She" could as well be designing these annoying "google doodles" and what other positions big corporation, like google, have for totally useless transgender fags, Google and Microsoft had to hire because of "gender diversity" political correctness.
Name:
Anonymous2013-07-02 12:01
>>81
That also explains Cudder's IE6 demoscene tendencies. A lot of web coding have ate "her" brain.
Name:
Anonymous2013-07-02 12:28
>>79 Recursion via a function call is NOT the same as a loop
Actually, assembly loop is a recursion.
In fact any (label label) pair juxtapostion serves as a self-reference (A -> A), linking label to itself.
>>79 Recursion via a function call is NOT the same as a loop
muh moot points
Name:
Anonymous2013-07-02 17:49
>>75 But if you ask me, needing an optimisation for it to be possible to do anything useful with the language at all is a big FAIL.
True, but what are the other possibilities? You can give up functional-style iteration or add an explicit tail-recursion construct like Clojure's recur. The latter clutters the code and the former is unsuitable in some cases, altough I do think so-called ``purely functional programming'' is inane and insane.
>>79 Recursion via a function call is NOT the same as a loop, because that's not how real machines work. Just because some theorist with his head in the clouds (and possibly high on something) showed how they are in theory doesn't mean it's true in practice.
Tail-call recursion is just one of the many ways of looping. HIBT?
>>75 You smug lisp weenies always bring up TCO like it's the ultimate solution to everything
I did no such thing. I simply used TCO as an example of how not everything that looks like a function call in Lisp necessary translates to a function call in machine code. If that were the case then TCO wouldn't be possible.
needing an optimisation for it to be possible to do anything useful with the language at all is a big FAIL.
It's a pretty trivial optimization. Just write a while loop that evaluates the expression until it's self-evaluating and you're done. Inlining is simple too. Just expand and reduce the expression until it's simple as possible. That can easily been done at compile time.
How hard is it to implement TCO and inline in C? The fact that C compilers hardly implement the former and can't even guarantee the latter should be a big giveaway.
But, I digress. Yes, C beats Lisp regarding raw speed. So? Who gives a shit? The guy writing for embedded hardware, sure. The guy writing the OS calls running constantly, sure. But if you care about nanoseconds at runtime in userland, then you're crazy. If you enjoy writing low-level code, good for you. If Lispers enjoy writing high-level code, good for them. Why do you care?
Name:
Anonymous2013-07-02 19:20
>>87
Raw speed is essentially the only thing that C has going for it. Acting like it's the only thing that matters is like giving the Best Picture Oscar to the shortest movie.
>>89
Yes. Lisp OS would have used Lambdas in place of syscalls and capabilities. Moreover, there would have been no unprotected memory accesses.
Name:
Anonymous2013-07-02 19:48
>>88
C/C++ still requires MMU for its speed. Had such MMU be provided say for Common Lisp, it would have been a lot faster than C/C++ due to microkernel design and array bound checking in hardware.
>>81-83
The other way around... I wouldn't consider myself a "web developer" at all, nor do I want to be associated with them. I just write web pages and scripts because I need to, not by choice. ("semantic web" and CSS evangelism, hating IE beyond reason, and superfluous use of JS and bloaty "frameworks" --- that's a "web developer". Not me.)
>>84-86
Recursion in the REAL WORLD is different. You can use it to REPEAT things like a loop, but that doesn't mean you should.
>>87-88 Yes, C beats Lisp regarding raw speed.
And overall efficiency, because you need far less memory.
>>92,93
C isn't for idiots who can't do simple maths. If you can't show what ranges an array index can take on or where a pointer can point, then either your code or your brain is buggy.
>>94,95
All unnecessarily complex solutions with more overhead than just stopping users from reaching outside the language interpreter.
THE OP IS NOT ME.
Name:
Anonymous2013-07-03 8:59
Anything with a smaller footprint than Java is good enough. And Haskell has a smaller footprint than Java. As for the lisp shit — well, who cares about it anyway.
Cudder are you one of those people who write for loops for graph traversal and such?
Name:
942013-07-03 10:33
nor do I want to be associated with them. I just write web pages and scripts because I need to, not by choice. ("semantic web" and CSS evangelism, hating IE beyond reason, and superfluous use of JS and bloaty "frameworks" --- that's a "web developer". Not me.)
I have to agree there.
All unnecessarily complex solutions with more overhead than just stopping users from reaching outside the language interpreter.
I was talking about what webhost use these days, that it does not matter what language you use on the system, the user will still be restricted unless a request is made otherwise, and the environment is fucking isolated. The reason PHP was even invented was to purposely screw small businesses with the pipe dream that there is language made ``just for HTML to make it less complex and cumbersome'', and slow down the market enough to make mini AIs in the already standard environments and automate most clients' requests. Read the history if you do not believe me: http://en.wikipedia.org/wiki/PHP#History
Heck, even Rasmus Lerdorf does what we do here at work: He rewrote these scripts in C for performance reasons, extending them to add the ability to work with web forms and to communicate with databases and called this implementation "Personal Home Page/Forms Interpreter" or PHP/FI. PHP/FI could be used to build simple, dynamic web applications.
>>98 hating IE beyond reason
Imagine writing a perfect C program, using every available feature of the ANSI C standard, then releasing it to the world and having 90% of users tell you it sucks and that you're a shitty programmer because your code didn't compile with one shitty compiler that just happens to be the most popular one in the world...that's IE.
>>100
Of course. Trees are recursive, graphs are not.
>>103 using every available feature of the ANSI C standard
That would be an incredibly stupid thing to do. If you manage to do such a thing your code would likely be excessively bloated and inefficient, not to mention obfuscated (you did say "every available feature", so I'll assume this means digraphs, trigraphs, 63-character-long identifiers, and everything else no regular C programmer ever cares about). The same applies to C++, but even more so.
>>107 WebKit power without Google's botnet.
Oh, you mean like Uzbl, Midori, Luakit, Surf, and every other browser J. Random Hacker threw together in his spare time?
>>107
E/g/in post, /g/roski. Would repost on le /g/reddit.
Name:
Anonymous2013-07-04 19:35
Linux Considered Harmful
Linux's success may indeed be the single strongest argument for my thesis: The excitement generated by a clone of a decades-old operating system demonstrates the void that the systems software research community has failed to fill. -- Rob Pike, original developer of Unix and author of The Unix Programming Environment
Everything in Linux sucks. For example, when I close "Nautilus" file manager window, it doesnt terminate program, but puts it in background. Why? To leak more CPU and memory! The xfce4-menu-plug already ate 140 megabytes of memory, and it's just a toolbar! When I try to `kill -s KILL gnome-screensaver`, it blanks whole screen and only reboot helps. Gedit (a simple notepad) takes whooping 60 megabytes to edit a few lines of text and it loads about 10 seconds! Opening a directory in file browser sometimes takes minutes, due to its file type detection feature (it scans and makes thumbnail of every file). Thousands of thumbnails stored inside ~/.thumbnails slow down image viewer startup by about 20 seconds. Invoking `cat` on a binary file damages terminal font and sometimes crashes bash.
Also, file type detection is extremely glitchy and detects unrelated files as PCX files. It also ignores file extension. So if it detects JPEG file as PCX, it will open it as PCX and crash viewer, despite that it has JPG extension.
Command Line interface is horrible at best! Sometimes a simple typo, like "cp *", can easily mess your files. The only way to be safe with Linux is to do backup every few hours.
Regarding bad design decisions in Linux: there is no sandbox and every program you run has access to all files inside you /home folder and can delete/steal them. Moreover every program gets internet access by default, making you machine a potential botnet node. That is a truly bad design decision, which could have been easily avoided by dropping unmanaged memory access or capability based security with array-bound checking protection, similar to one specified in http://www.cs.ucr.edu/~gupta/teaching/260-08/Papers/TR181.pdf
Unauthorized program should't be able to access filesystem or internet. Every program should be limited in access only to files and directories provided by the user, while internet access is given only to programs installed under apps.interned_allowed directory. There should be a way to reject privileges given to file/directory handles, so accessing them would produce exception. Users shouldn't see outside of their home directory and all file-sharing should be explicit. User password should be too kept under's home directory, so it could be changed without much fuzz with /etc/passwd.
Super user rights can't be managed precisely and every program requiring them has to be given full super-user account (setuid/setgid). No on/off switches, so a program wanting direct access to SVGA frame buffer also gets access to network connection and whole hard drive content.
POSIX API is horrible and includes a lot of undefined behavior. A change to memcpy implementation once broke tons of Linux code that depended on undefined behavior. But Worse is Better, of course (http://www.cygwin.com/ml/glibc-bugs/2011-02/msg00090.html). Production Linux code almost completely consists of ugly hacks, like following: __pid_t __cdecl sub_813C7B8()
{
__pid_t result; // eax@1
char command; // [sp+18h] [bp-200h]@2