Reverse functional programming
-
@blakeyrat said:
@Ben L. said:
Here's a program that uses 5000 goroutines. Try that with threads. I dare you.
5000 threads? I have a webserver that does that in its sleep.
BTW, wasn't Go written in 2007? Why the fuck does it refer to "procs" and not "cores"? I mean, who gives a shit in 2013 (or 2007 for that matter) how many physical processors are in the machines when only cores matter? Are "procs" really "cores"?
For that matter, how does it handle hyper-threading? Do those count as "procs"?
How it is possible for a language designed in 2007 to:
1) Not support Unicode? (Meaning: it has a fundamental feature that breaks in languages without capital letters. For you pedantic dickweeds.)
2) Have such a poorly-worded environment variable?Who ever decided they were "cores?" A processor is a procesor, regardless of packaging.
-
@bridget99 said:
Who ever decided they were "cores?" A processor is a procesor, regardless of packaging.
You're trolling, but I'll answer since some other retard on this forum is undoubtedly nodding their head and thinknig, "good point Bridget99!!!"
The company that makes the processors gets to decide on what they're called. And they've decided the physical item is a "processor," which contains multiple "cores," each of which contains (potentially) multiple "hyper-threads," each of which contains multiple "execution units."
-
Unicode does have a few problems. I wouldn't want Right-to-left override in variable names, for example (or in many other places). But I don't see how a few sane whitelists wouldn't be able to solve that problem.
-
@blakeyrat said:
@bridget99 said:
Who ever decided they were "cores?" A processor is a procesor, regardless of packaging.
You're trolling, but I'll answer since some other retard on this forum is undoubtedly nodding their head and thinknig, "good point Bridget99!!!"
The company that makes the processors gets to decide on what they're called. And they've decided the physical item is a "processor," which contains multiple "cores," each of which contains (potentially) multiple "hyper-threads," each of which contains multiple "execution units."
Oh, OK. I make computer programs. From now on, I choose to call them Manticore Marbles.
-
@spamcourt said:
Unicode does have a few problems. I wouldn't want Right-to-left override in variable names, for example (or in many other places). But I don't see how a few sane whitelists wouldn't be able to solve that problem.
Yeah, I realize that a lot of the worst Unicode problems have basically been worked around. I guess the question here is (as it so often is), "do we tolerate a bunch of kludges or do we aspire to something better?"
-
-
@morbiuswilters said:
@Ben L. said:
Try that with threads. I dare you.
Are you joking or something? I use 5000 threads all the time.
You use 5000 threads that have to communicate data with each other and it completes in well under a second?@morbiuswilters said:
Although, you did inadvertently answer a question I posed awhile back, which was what the hell was different about Go's threads. So it turns out Go threads are just pretend threads which are scheduled on top of a pool of real threads. While it's nice they made that idiom easy to implement, it's not new or novel in any way. And I wonder how well the Go scheduler is under heavy load.
There are no "new ideas" in Computer Science.
-
@Ben L. said:
You use 5000 threads that have to communicate data with each other and it completes in well under a second?
Yes? Although from the stuff you've posted, you seem to be under the impression that the point of threads is to take some large task and break it down so each instruction uses its own thread. Otherwise I don't understand why you keep posting contrived examples using 5000 threads to calculate pi. Who would do something like that? That's not what threads are made for. I think Go has rotted your brain.
-
-
@Ben L. said:
You use 5000 threads that have to communicate data with each other and it completes in well under a second?
No. It's a fucking WEB SERVER. Why would they interact with each other? That's not the point.
I guess they all could potentially interact with ASP's Web.Cache object, but that's about it.
-
@Ben L. said:
Here's a program that uses 5000 goroutines. Try that with threads. I dare you.
Do you have any examples of Go for things that people might actually want to do, and where doing it in Go actually has any advantages? Because I've never seen one.
-
@Vanders said:
@Ben L. said:
Here's a program that uses 5000 goroutines. Try that with threads. I dare you.
Do you have any examples of Go for things that people might actually want to do, and where doing it in Go actually has any advantages? Because I've never seen one.It can take the square root of 4 20,000 times, with each function call having its own stack, and it can do it with lightning speed. Try that with threads, l00zurz!
-
There's a part of me that says "fancy approaches to parallelism are bad, because they make the remaining race conditions and such even more subtle." Discuss.
-
@bridget99 said:
There's a part of me that says "fancy approaches to parallelism are bad, because they make the remaining race conditions and such even more subtle." Discuss.
There's a part of me that says "having the townsfolk stone bridget is bad, because then the new guillotine we spent all that money on goes unused." Discuss.
-
@morbiuswilters said:
@bridget99 said:
There's a part of me that says "fancy approaches to parallelism are bad, because they make the remaining race conditions and such even more subtle." Discuss.
There's a part of me that says "having the townsfolk stone bridget is bad, because then the new guillotine we spent all that money on goes unused." Discuss.
Oh, come on; I had an honest computer question there!
-
@blakeyrat said:
@Ben L. said:
You use 5000 threads that have to communicate data with each other and it completes in well under a second?
No. It's a fucking WEB SERVER. Why would they interact with each other? That's not the point.
Well if you wanted a web server why didn't you just say web server?
But seriously, 5000 threads? Here's a program you should run and give me the output of:
#include <stdio.h> #include <windows.h>
DWORD CALLBACK ThreadProc(void*)
{
Sleep(INFINITE);
return 0;
}int __cdecl main(int argc, const char* argv[])
{
int i;
for (i = 0; i < 1000000; i++) {
DWORD id;
HANDLE h = CreateThread(NULL, 0, ThreadProc, NULL, 0, &id);
if (!h) break;
CloseHandle(h);
}
printf("Created %d threads\n", i);
return 0;
}
Your favorite blog states that 2000 threads is about 2GB of memory, and all these threads do is sleep. Now imagine some kind of complex server process, and 2.5 times as many threads.Creating threads is expensive. Go simply builds an easy way of pooling them into the language.
-
@Ben L. said:
#include <stdio.h>
#include <windows.h>DWORD CALLBACK ThreadProc(void*)
{
Sleep(INFINITE);
return 0;
}int __cdecl main(int argc, const char* argv[)
{
int i;
for (i = 0; i < 1000000; i++) {
DWORD id;
HANDLE h = CreateThread(NULL, 0, ThreadProc, NULL, 0, &id);
if (!h) break;
CloseHandle(h);
}
printf("Created %d threads\n", i);
return 0;
}
Why would you create a million threads? That's just asinine. If you think this is a meaningful example, you have no idea what you are talking about.
@Ben L. said:
Your favorite blog states that 2000 threads is about 2GB of memory, and all these threads do is sleep. Now imagine some kind of complex server process, and 2.5 times as many threads.
Whoever has heard of a computer with 5GB of RAM!? Oh my word!
@Ben L. said:
Creating threads is expensive. Go simply builds an easy way of pooling them into the language.
OS threads aren't that expensive. At the same time, for certain use-cases like I/O-heavy operations, event-driven systems are better. None of that is really pertinent here, though, because every example you give seems to show you have no conception of what a thread is or what it is used for. Go's multi-processing facility is interesting, but it's not really comparable to threads.
I'm going to blow your mind here: you do realize that, at some level, goroutines are built on top of icky old threads, right? That other people might have, as the Go programmers have, a need to utilize threads?
The thing is, I could actually imagine some cases where Go's multi-processing model would be useful, but you haven't provided a single one. What's more, I would never suggest that goroutines are a substitute for threads--they solve similar-yet-distinct problems in different ways.
-
@Ben L. said:
Here's a program that uses 5000 goroutines. Try that with threads. I dare you.
Or you could just use a sane language:
public static double Pi(int n) { var terms = from k in Enumerable.Range(0, n + 1).AsParallel() select Term(k);return terms.Sum();}
private static double Term(int k)
{
return 4 * Math.Pow(-1, k) / (2 * k + 1);
}
-
I could see it being handy maybe if you were writing a server meant to service thousands of persistent concurrent client connections.
-
@Salamander said:
@Ben L. said:
Your definition of "sane language" has SQL as part of it?Here's a program that uses 5000 goroutines. Try that with threads. I dare you.
Or you could just use a sane language:
public static double Pi(int n) { var terms = from k in Enumerable.Range(0, n + 1).AsParallel() select Term(k);return terms.Sum();}
private static double Term(int k)
{
return 4 * Math.Pow(-1, k) / (2 * k + 1);
}
-
@Ben L. said:
Your definition of "sane language" has SQL as part of it?
Saner than yours.
By the way, goroutines exist in C# as async methods
The difference is you have a lot less contol over them in Go and it's a lot harder to tell when a goroutine will wait.
-
@joe.edwards said:
I could see it being handy maybe if you were writing a server meant to service thousands of persistent concurrent client connections.
I guess, although it is significantly less mature than C, Java, C#, Python or Perl. And you can easily support thousands of concurrent client connections using threads, or even more if you use async I/O.
-
@morbiuswilters said:
@joe.edwards said:
I could see it being handy maybe if you were writing a server meant to service thousands of persistent concurrent client connections.
I guess, although it is significantly less mature than C, Java, C#, Python or Perl. And you can easily support thousands of concurrent client connections using threads, or even more if you use async I/O.
Yes, you can use 10000 threads. Or you can use 10 threads and spawn a goroutine per request.
-
@Ben L. said:
Yes, you can use 10000 threads. Or you can use 10 threads and spawn an asynchronous method call per request.
FTFY
-
@bridget99 said:
@Cenan said:
- Properties. What the fuck are you talking about? If your properties are sugar, you're doing it wrong. There is good reason for keeping the getter and setter together, and I get you think that's way worse than naming every other method get* or set* and having them strewn all over the place, cause the code is prettier that way.
- Events. What the fuck are you talking about? If you need to un-wire an event, keep a fucking reference around for the EventHandler. That's like crying that malloc() is broken cause your piece of shit app is leaking like the Titanic, and free() as hard to use cause you'd have to hold a valid reference.
- Exceptions. You're right. That you can't see the potential exceptions a method throws is retarded. Most of Microsoft's own .Net libraries document their exceptions very well though, so that may be down to your own lack of documenting skill
- XML Comments: What the fuck are you talking about? If you don't like comments that has in-tool support for creating documentation, don't use them. Shit.
Properties: What I would suggest is get/set methods grouped together. No, you don't have to group your methods together, any more than a C# programmer has to avoid creating quasi-fields. Either way, it's possible to screw things up, and my opinion is that creating quasi-fields is the biggest potential screw-up in play here. Eliminating properties doesn't completely address the issue, but in my experience having properties does encourage making quasi-fields. It allows developers to get rid of fields in a cosmetic way that does nothing but sweep the real problem under the rug.
Events : I don't think the unwiring technique you're describing actually works. In .NET 1.0 and 1.1, the only C# syntax for unwiring events was:
myconrol.Clicked-=new EventHandlerType(myMethod);
I am fairly certain this was the only way to do this. I remember trying what you suggested (maintaining a reference) but it did not work. Later (.NET 2.0?), the syntax shown below became allowable:
mycontrol.Clicked-=myMethod;
This is an improvement, but really, the use of += and-= is infantile.
XML Comments: what you say is reasonable. I still hate them though. I've sifted through too much boilerplate crap to ever really feel enthusiastic about that sort of thing.Events: Religious zealotry is for the Stallman's of the world. Not being able to revise an opinion, even when you recognize that it's dated and based on a version of the software from a decade hence, is what is infantile. I admit I'm too
busylazy to double
check if what you say is true, so I'll assume that it worked that way
in .Net 1.1. So you'd have to instantiate a new EventHandler to be able
to un-wire an event? The WTFness of having that problem in the first
place aside, so what? Nobody holds a reference to the instance so it'll
be marked for collection very shortly anyways. It's a waste true, but
not game breaking. You could always upgrade your implementation to something not so ancient. The Linux kernel pre 2.6 used the BigKernelLock all over the place, effectively making the entire kernel single-threaded, therefore any Linux installation of any version is infantile and completely borked.Properties: There is good reason for wanting to group them together. One of the core principles in OO-programming is encapsulation. Forcing the get/set methods into the same {} block makes, to me at least, perfect sense. You can't hide your getter or setter below 200 lines of code, or smatter them all over the place, you can't name them billyBob1 and billyBob2. You can still place your backing field someplace else, but that is another WTF.
You could always argue that the syntax is weird, or that you can do stupid shit like public string Value { get; set; } really should be taken out. But that's not so much a problem of the language, but a problem with the developer not getting the point. Hiring someone who would do that sort of thing in production code is TRWTF.
XML Comments: I agree wholeheartedly that a lot of developers don't have fuck all clue what do to with all that boilerplate. That again is a problem with the developer, not so much with the feature. I like XML comments, and use the extensively because the code I create is used by other people, and them being able to see exactly what a method does and what condition their instances are in after a call, is very much worth it. And with a little bit of effort you can use that boilerplate to create very consistent documentation. You can even flip a compiler switch and ship your library complete with in-tool documentation, without exposing your implementation details. Neat huh?However, there are a number of other concerns with the boilerplate XML that would have made much more sense to point out. Like, why doesn't the standard implementation create nodes for exceptions? Why is it that the framework can't seem to figure out what a line break is, unless you put <para> in everywhere? Why is there a node for <returns> but you can't see it in the IDE, it only shows up when you generate your documentation.
-
@Ben L. said:
Yes, you can use 10000 threads. Or you can use 10 threads and spawn a goroutine per request.
Yes, I already said this. It's well-established at this point that goroutines can be used as a mutli-processing model. You're just ignoring the points that I made, about how you can do this in numerous other languages; how far more mature languages exist; how I don't see anybody using Go in serious production; how all of your examples of Go code so far have been badly contrived; how you are drastically misrepresenting and/or misunderstanding threading as it is used in hundreds of thousands of applications..
Virtually every big iron application in production uses threads, and with good reason. How many large, mission-critical deployments are there running on top of goroutines?
-
@joe.edwards said:
@morbiuswilters said:
Is that why they go completely the opposite way, and they all use the Nagesh account?@blakeyrat said:
Blakey doesn't have alts.
I don't either. I hope nobody does; the thought of someone going to the effort of sockpuppeting on this forum is too depressing to contemplate.
In Hyderabad, nobody is having the alternate account. Is punishable by death.
-
@morbiuswilters said:
bla
Your animated sig is annoying me to no end.
Beware. I have a purple dildo picture at the ready.
-
@morbiuswilters said:
Virtually every big iron application in production uses threads, and with good reason. How many large, mission-critical deployments are there running on top of goroutines?
Who knows? Who cares? I suspect you're sharp enough to understand that that's not really an interesting argument. Anyways, I found this list.
BTW, I want to congratulate you guys. You've nearly perfected the bridget style of trolling in this thread. If only all applications were web servers...
-
@morbiuswilters said:
How many large, mission-critical deployments are there running on top of goroutines?
Argh! It itches my brain every time somebody uses their made up word "goroutines".
It's great that the language provides an async model, sure, whatever, but wtf was wrong with just calling them coroutines? Is there some distinction I'm missing?
-
@bridget99 said:
Oh, OK. I make computer programs. From now on, I choose to call them Manticore Marbles.
Go ahead. You were already making a conscious choice to use a different name by saying computer programs instead of software or apps anyways.
-
@Ben L. said:
Well if you wanted a web server why didn't you just say web server?
I did say it was a web server.
@Ben L. said:
Your favorite blog states that 2000 threads is about 2GB of memory, and all these threads do is sleep.
And this is... a practical example?
Also, 2 gb? Oooo I'm shaking in my boots! The web server has 12 GB of memory, and that's tiny for a web server.
@Ben L. said:
Go simply builds an easy way of pooling them into the language.
And IIS pools threads too, because it's not antediluvian.
So Go provides... what benefit exactly?
-
@blakeyrat said:
@Ben L. said:
Go simply builds an easy way of pooling them into the language.
And IIS pools threads too, because it's not antediluvian.
So Go provides... what benefit exactly?
Holy shit! When did IIS become a programming language?!
-
@boomzilla said:
Holy shit! When did IIS become a programming language?!
Holy shit when did Boomzilla become an idiot? Oh yeah right after birth.
It doesn't matter whether the thread pooling is provided by the programming language or the runtime, the point is I still have it easily available. Saying, "oh IIS doesn't count because it's not a programming language" or "ADO.net doesn't count because it's not a programming language" is just implementation-detail. The FUCKING POINT is that this new and shiny feature of Go, I've had available to me for many, many years now. So I don't give a shit.
We're all still waiting for Ben L to give us a Go example that isn't contrived and makes it look like a language that's actually good for some task. It's just that none of us know what that task might be...
-
@aihtdikh said:
It itches my brain every time somebody uses their made up word
You probably wouldn't want to read anything by Frank Herbert then, whose works defy this picture of Rosie O'Donnell:
-
@blakeyrat said:
It doesn't matter whether the thread pooling is provided by the programming language or the runtime, the point is I still have it easily available. Saying, "oh IIS doesn't count because it's not a programming language" or "ADO.net doesn't count because it's not a programming language" is just implementation-detail. The FUCKING POINT is that this new and shiny feature of Go, I've had available to me for many, many years now. So I don't give a shit.
You really can't see that what you're saying is a non sequitur? I guess I shouldn't be surprised.
OK, fine, what you get from IIS is kinda similar to the apparent concurrency model of Go. And that's fine if you're serving up web pages. And sure, some other languages have similar things by different names that may or may not be as easy as whatever Go does (most of my exposure comes from BenL's posts here, frankly). But so what? That was just an example of how Go might be able to do something similar to other useful apps. To come back and say that useful apps already do that just demonstrates that you don't really have an argument.
@blakeyrat said:We're all still waiting for Ben L to give us a Go example that isn't contrived and makes it look like a language that's actually good for some task. It's just that none of us know what that task might be...
Yawn. He showed some simple, trivial things that it does. If he posted something nontrivial, you'd just moan that you couldn't understand all of that crazy stuff and didn't have a need for it anyways. I know, doing parallel computations isn't very important for serving up My Little Pony porn, so it's beyond your capability or imagination. I think some others are just trolling, but I do think that you're this stupid.
My impression of Go is that it has some interesting ways of doing things. I don't have the time to dig into it, but I would like to. Fortunately, I'm able to think beyond whatever MS's current Big Thing is, and I've noticed that the world of computers is bigger than web pages.
Eh...on second thought, blakeyrat is doing OK with what he has now. That proves that there's nothing interesting here.
-
@joe.edwards said:
@aihtdikh said:
It itches my brain every time somebody uses their made up word
You probably wouldn't want to read anything by Frank Herbert then, whose works defy this picture of Rosie O'Donnell:
Not to mention Shakespeare. That guy made up more words than anybody.
-
@dhromed said:
Your animated sig is annoying me to no end.
Mission Accomplished.
@dhromed said:
Beware. I have a purple dildo picture at the ready.
Secondary objectives in sight.
-
@boomzilla said:
Who knows? Who cares? I suspect you're sharp enough to understand that that's not really an interesting argument.
No? Every point Ben L. has made in this thread has been some ridiculous example like "Could you launch a trillion threads? No? Well, Go can calculate Pi using this really ridiculous algorithm, which even the source I linked to admits is stupid!"
@boomzilla said:
Anyways, I found this list.
That reads like a list of orphans who are dying of puppy cancer. It's sad. I only recognize 3 of the names on there: Canonical, BBC and Heroku, and those are mostly fail.
@boomzilla said:
BTW, I want to congratulate you guys. You've nearly perfected the bridget style of trolling in this thread. If only all applications were web servers...
I would suggest Ben L. is the one who is trolling, except, sadly, I think he is sincere. I've said all along that goroutines are a useful abstraction for multi-processing, but that they aren't a replacement for threads in many contexts and every single point Ben L. has made has been a ridiculous misrepresentation of how threads work or why people use them.
-
@boomzilla said:
That was just an example of how Go might be able to do something similar to other useful apps. To come back and say that useful apps already do that just demonstrates that you don't really have an argument.
I'm really shocked at how badly you have mischaracterized the debate here. Did you actually read the whole thread? I never said goroutines were useless, it's Ben L. who's insisting they're some replacement for threads in every single context with silly "examples". (Still, I'd never write production software in Go for the simple reason that it's not a mature language and it would be engineering malpractice to expend tens of thousands of company dollars building something on an obscure language for no good reason.)
-
@morbiuswilters said:
@boomzilla said:
That was just an example of how Go might be able to do something similar to other useful apps. To come back and say that useful apps already do that just demonstrates that you don't really have an argument.
I'm really shocked at how badly you have mischaracterized the debate here. Did you actually read the whole thread? I never said goroutines were useless, it's Ben L. who's insisting they're some replacement for threads in every single context with silly "examples". (Still, I'd never write production software in Go for the simple reason that it's not a mature language and it would be engineering malpractice to expend tens of thousands of company dollars building something on an obscure language for no good reason.)
Yes, I've followed the thread from the beginning. You need to go back and see what he and blakey were on about. What I got from BenL's point here was basically that Go had built-in thread pooling at the language level. At which point, blakey decided that was stupid, because he has an application that does some thread pooling things for him.
I agree that BenL's examples haven't been particularly useful. But if he threw out the same things for C#, that wouldn't make C# completely useless or without any interesting features. If we can draw conclusions only based on the arguments and examples provided, and cannot extrapolate at all, then I agree, BenL has lost the debate. But it's not so obvious from a non-pedantic dickweed / angry forum troll perspective.
I'm not interested in writing any sort of production thingamabob in Go, either, for similar reasons, but that doesn't mean all that much as far as the design of the language. Anyways, people write far more mission critical stuff using far worse tools. Blakey's nonsense is particularly amusing, since he loves to go on about how no one is ever interested in innovation (except those statistical user experience whizzes as Microsoft), but any attempt at such is greeted with capitalized profanity. I guess his account would be suspended for suspicion of being hacked if anything else happened, so that's OK.
-
Can anyone name an interesting example of threads that can be shown in under 100 lines of code? No? Because applications of threads are either so simple it hurts or useful (but only if you know every aspect of the program they're being used in)?
There, just summarized this entire argument.
-
-
@blakeyrat said:
@Ben L. said:
under 100 lines of code?
Where did that requirement come from?
Everyone knows that software over 100 lines is useless!
-
@blakeyrat said:
@Ben L. said:
under 100 lines of code?
Where did that requirement come from?Are you serious? How do you stay employed with communication and reasoning skills like this? Do the orderlies allow you to have silverware?
-
@Ben L. said:
Can anyone name an interesting example of threads that can be shown in under 100 lines of code? No? Because applications of threads are either so simple it hurts or useful (but only if you know every aspect of the program they're being used in)?
There, just summarized this entire argument.
Here ya go: 22 lines and about as interesting as anything you shown..
<html><body style='color:#000000; background:#ffffff; '>
#include <stdlib.h> #include <stdio.h> #include <pthread.h> void * _stupid_main(void *a) { int *i = (int *)a; printf("%i: %s\n", *i, ((*i % 2) ? "ODD" : "EVEN")); } int main() { pthread_t *th; th = calloc(5000, sizeof(pthread_t)); int *ints; ints = calloc(5000, sizeof(int)); for (int i = 0; i < 5000; ++i) { ints[i] = i; pthread_create(&th[i], NULL, _stupid_main, &ints[i]); } }
It spawns 5000 threads, each one with a number 0-4999, and prints whether it is odd or even. It runs in 0.11s on my aging laptop (which apparently is impossible with threads, I guess..)
-
@morbiuswilters said:
@boomzilla said:
Made even more so by the BBC link being to Quora, one of the more odious sites I've experienced.Anyways, I found this list.
That reads like a list of orphans who are dying of puppy cancer. It's sad. I only recognize 3 of the names on there: Canonical, BBC and Heroku, and those are mostly fail.
-
@morbiuswilters said:
Here ya go: 22 lines and about as interesting as anything you showed..
I CANNOT TAKE YOU SERIOUSLY. YOU DIDN'T RETURN ANYTHING FROM MAIN.
-
@morbiuswilters said:
@Ben L. said:
Can anyone name an interesting example of threads that can be shown in under 100 lines of code? No? Because applications of threads are either so simple it hurts or useful (but only if you know every aspect of the program they're being used in)?
There, just summarized this entire argument.
Here ya go: 22 lines and about as interesting as anything you showed.
You did not disprove my point. My point was that any interesting program that uses threads would be longer than the attention span of the average TDWTFer would allow. That includes abstractions of threads, like goroutines and whatever the hell C# calls its version.
-
@Ben L. said:
My point was that any interesting program that uses threads would be longer than the attention span of the average TDWTFer would allow.
I don't think there's any interesting program that fits into 100 lines.
@Ben L. said:
That includes abstractions of threads, like goroutines...
Soo.. you're basically admitting that nothing you've posted in this thread is interesting and that Blakey is correct?
