Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Evaluation Order Sucks

Name: Anonymous 2014-07-14 0:56

Just fixed an error with
array[count++]= foo();
where foo() modified count, in effect writing stuff into the incorrect location.

Haskell's lazy evaluation would have prevented that.

Name: Anonymous 2014-07-14 1:15

Why would you ever make a non-parametric function modify some kind of counter variable?

Stop trying to market Haskell with your synthetic ``human errors'' that never actually happen to anyone with a brain. Haskell can't magically fix stupid and all your scenarios have been a severe case of stupid. This is ``put braces around one-liner ifs'' all over again.

Name: Anonymous 2014-07-14 1:22

I have C's order of operations tattooed on my right arm.

Problem solved.

Name: Anonymous 2014-07-14 1:26

Don't use global variables, Ahmed

Name: Anonymous 2014-07-14 1:35

>>4

This is C. No rules. You can use everything, including goto.

Name: Anonymous 2014-07-14 1:39

Kitchenware Sucks

I just bandaged my arm after cleaving it off with a knife which, in effect dismembered me by separating the arm from the rest of my body.

Using a spoon would have prevented that.

Name: Anonymous 2014-07-14 1:40

>>1
That's UB -- as is m[c++] = c++.
>>2
Why would you ever make a non-parametric function modify some kind of counter variable?
clearerr();
This is ``put braces around one-liner ifs'' all over again.
I don't do that.
>>3
What about your left arm?
>>4
shut the fuck up, John.
>>5
Read C11 (yes, da standard).

Lastly, fuck off with your shit >>6. Everything has been answered in >>1-5

Name: Anonymous 2014-07-14 1:49

Any programmer who blames the lasagna for his inabity to work is really an attention whore with a persecution complex. This is on the same level as doing int main = 5; and then saying the compiler made you do it. It's obviously wrong. Why would you ever write code that way?

Name: Anonymous 2014-07-14 1:54

>>7
On my left arm I tattooed a list of the minimal set of primitives needed to implement a Lisp Machine.

Name: Anonymous 2014-07-14 1:55

>>7
clearerr is unary, so the modification of the argument is apparent.

Name: Anonymous 2014-07-14 2:19

>>7
Why would you ever make a non-parametric function modify some kind of counter variable?

clearerr();

u mena

void clearerr(FILE *stream);

which requires that you specify the stream that is to be modified?

There are no nice words for people who write functions that implicitly modify state that isn't specified via an input parameter. The people who put that kind of crap in the C stdlib have been openly regretting it for decades now.

Name: >>6 2014-07-14 3:56

>>7
Fuck you you little insufferable shit.

Name: Anonymous 2014-07-14 5:42

>>1
If you can't stand the heat, get out of the kitchen; etc.

Name: Anonymous 2014-07-14 8:10

You fuckers sure get angry at the slightest hint of YHBT, don't you!

Name: Anonymous 2014-07-14 8:14

NIGGER

Name: Anonymous 2014-07-14 8:59

>>2
``human errors'' that never actually happen to anyone with a brain
There's nothing synthetic about it. >>1 may be full of shit, but so are you. Much of the software we all rely on is written by the brainless, to put it your way. The problem can be reliably solved with the appropriate aliasing semantics. They also provide thread safety.

Name: Anonymous 2014-07-14 11:57

global variables
There is not such thing called a ``global variable'' in C, maybe you are talking of variables declared in the file scope? tsk.

Name: Anonymous 2014-07-14 12:33

>>17
Isn't file scope when you use static outside of a function?

Name: Anonymous 2014-07-14 14:11

>>9
Forced GC wouldn't fit on your arm.

Name: Anonymous 2014-07-14 14:47

>>19
Lisp doesn't imply GC.

Unless you go full retard and start using cyclic data structures.

Name: Anonymous 2014-07-14 14:50

>>20
Show me a Lisp without forced GC.

Name: Anonymous 2014-07-14 15:25

>>1
Evaluation Order Sucks
Then why does Haskell have seq?

Name: Anonymous 2014-07-14 15:28

>>22
Because Haskell sucks

Name: Anonymous 2014-07-14 15:36

Seq breaks the fusion laws.
UnsafePerformIO breaks the fusion laws.
Haskellers keep blabbering about how cool Haskell is for supposedly making stream fusion possible because it supposedly is a pure language.

Name: Anonymous 2014-07-14 16:37

>>16
The example, a parameter-less functions modifying what looks like a local variable, isn't your average error out of carelessness. In fact, you'd need to take serious effort in order to get this running in the first place. All this software written by the brainless may be bad, but it isn't that bad. It can't be that bad because a brainless one wouldn't do the amount of pointer magic necessary for this scenario. >>1-san's scenario is about as synthetic as it gets.

I'd love to see how you'd solve this specific problem with aliasing semantics, but in total, I'm convinced that Dijkstra was right: Basic mathematics (think on level of Calc I) should be a requirement for programming, if only to keep the toilet scrubbers out.

Name: Anonymous 2014-07-14 17:40

>>19
You can implement GC with those primitives, presumably.

Name: Anonymous 2014-07-14 17:48

>>21
http://home.pipeline.com/~hbaker1/LinearLisp.html

I'm not saying it's the best we can do, I'm just showing you an example as per your request.

Name: Anonymous 2014-07-14 18:40

>>25
It is that bad. Sometimes its a typo, sometimes its something analogous to >>1's code, but less obvious: for(whatever) { array[next_location()] = foo(); } Even >>1's code happens. Global state is very common in C, look at any non-threadsafe library.

Good aliasing rules simply makes it impossible to compile the code in >>1. Having multiple references to mutable state is wrong.

Dijkstra wasn't wrong, but that kind of math doesn't help with this. You need another kind of math, the kind that makes you wonder what advantage people see in languages with such shortcomings.

Name: Anonymous 2014-07-14 19:49

>>28
The advantage is that you're not so thoroughly straitjacketed you can't even write "hello world" without a PhD in category theory.

Name: Anonymous 2014-07-14 20:07

>>29
Too obvious.

Name: Anonymous 2014-07-14 20:44

Name: Anonymous 2014-07-14 20:46

>>21

Symta. It uses just stack and GC invoked only when user wants to. Although Symta require carefully planning what you return, because once you return something to the upper stack level, it is here to stay. But that is predictable.

Name: Anonymous 2014-07-14 21:50

>>31
Oh right, forgot about that.

Name: Anonymous 2014-07-14 23:37

>>28
Global state is very common in C, look at any non-threadsafe library.

Global state is also trivially avoidable in C, and any decent library avoids it. The fact that things like the C standard library have global state isn't evidence that global state is OK; if anything all the effort that has gone into standardizing thread safe alternatives to old stdlib functions demonstrates the exact opposite.

Having multiple references to mutable state is wrong.

Maybe so, but C does nothing to enforce this. Not having anything in the global scope makes it that much harder for it to happen by mistake.

Name: Anonymous 2014-07-15 2:22

Function application is relatively expensive on conventional computers. The principle reason is the complexity of maintaining the data structures that support access to the bound identifiers. The problems are especially severe when higher-order functions are permitted. Because a formula of the SKI calculus contains no bound identifiers, its reduction rules can be implemented as simple data structure manipulations. Further, the reduction rules can be applied in any order, or in parallel. Thus it is possible to design massively parallel computers (graph reduction machines) that execute functional languages efficiently.

Then why aren't we using the SKI calculus everywhere?

Name: Anonymous 2014-07-15 2:27

>>28
Having multiple references to mutable state is wrong.
Only if you're a stupid Haskeller like OP. Having multiple refs to mutable state allows for efficient broadcasting. E.g. you can have a tree of data with a mutable leaf, there is one mutator of that leaf and several listeners. As soon as the mutator updates the leaf, all the listeners see the change. No expensive sub-tree rebuilding and reallocation required as in immutable data structures. This is very handy in e.g. video games.

Name: Anonymous 2014-07-15 2:36

>>35
Then why aren't we using the SKI calculus everywhere?

because we don't have massively parallel computers

Name: Anonymous 2014-07-15 5:25

>>34
Global state is also trivially avoidable in C

And yet many important libraries depend on it. I wish I had been tracking examples but all I can say is I'm disappointed but not surprised by how often this happens.

Thread-safe alternatives in the standard library is a fine thing, but it requires passing around an environment. It's not a big hassle when the environment won't outlive the frame its created in, but it's unattractive to libraries where the environment (or context) would be created close to main and passed all over, along with any other environments.

Maybe so, but C does nothing to enforce this. Not having anything in the global scope makes it that much harder for it to happen by mistake.

No argument here, but I am arguing against using C where possible.

>>36

Can you express your point in a way that doesn't rely on the immutable data structures or some other strawman?

Name: Anonymous 2014-07-15 6:13

>>34
Global state is also trivially avoidable in C
What about rand/srand?

Name: Anonymous 2014-07-15 6:51

>>38
Thread-safe alternatives in the standard library is a fine thing, but it requires passing around an environment. It's not a big hassle when the environment won't outlive the frame its created in, but it's unattractive to libraries where the environment (or context) would be created close to main and passed all over, along with any other environments.

So it goes. If you don't do that from the start eventually someone will start asking for multiple environments in the same application and then you will really be screwed. Library authors seem to endemically underestimate the need for this.

>>39
We were discussing shared libraries. Random number generation is coupled to IO and is really an operating systems issue; if you want a decent entropy source you are going to need to deal with synchronizing access to some global shared state.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List