Threading: real pain or just whining?

http://www.codinghorror.com/blog/archives/000169.html

Aside from the VB.net faggotry, and the date of the post (2004 lol), i don't understand why is this people so scared of threads. Right, they add complexity, and a different way of considering problems, but sounds like they are trying to use them in the wrong place (like, everywhere). IMO, proper isolation and adequate locking for thread communication is enough, and doesn't really add any potential flaws to the code.

This book is written for VB developers
This book is written for VB developers
This book is written for VB developers
This book is written for VB developers
This book is written for VB developers
This book is written for VB developers
This book is written for VB developers
Thread over.

>>2
I believe Dan's cautionary tale applies to virtually all developers currently working in Windows. Programming with threads is hard because:

 • our current programming models don't deal with concurrency well
 • most of the programming we do is linear in nature
 • programmers have a hard time thinking in terms of events than can interrupt each other at any time
 • i'm a whining bitch.


Thread continues

codinghorror.com

joelonsoftware.com

prog.org

>

myothercar.com

myothercar.com.    86400    IN    CNAME    cdr.com.

Developers on Windows! Hah! No serious develop uses that platform.

BAWWWWWWWW I'M TOO STUPID TO KNOW HOW TO USE THREADS BECAUSE I'M A VB CODE-WRITER

sage for VB tripe.

VBCODE

Perhaps with a language that has better treatment of concurrency, DAN would not be such a whiny bitch.

My other CAR is a C.A.R. Hoare.

My other C.A.R. Hoare is a a whore

because of that link i ended up reading about xbox multicore issues from john carmack and then perusing the java.util.concurreny class docs by doug lea. thank you for reminding me that i suck at programming compared to those people

>>16
You suck at programming compared to /prog/, because you were interested in java/microsoft topics.

The game, you have just lost it

>>17
faggot

Threads are not the only way to implement concurrency

(don't tell it to Windows programmers).

I prefer to minimize thread use if possible. I am a big fan of using select()/poll() in enterprise servers

>>20 Told you -- do't tell it to Windows programmers.

>>17
he doesnt completely suck at programming, since he read a john carmack post and john carmack said, and I quote:
[quote]The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.

 

I spent a fair amount of time looking at java byte code disassembly while optimizing my little rendering engine. This is interesting fun like any other optimization problem, but it alternates with a bleak knowledge that even the most inspired java code is going to be a fraction the performance of pedestrian native C code.[/quote]

>>22
even the most inspired java code is going to be a fraction the performance of pedestrian native C
INCORRECT

With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.
Fucking true. Many phones nowadays (even the cheap ones) are built around an ARM7/9 core and can hardly display a dozen of polygons per frame because of this fucking bloated shit. And it's not even portable.
In a perfect world, we would have a common C API (for thing like sound, 3D, input, video, network...) for ARM phones and we would be able to run ARM binaries directly on the phones, but that's not going to happen anytime soon.

>>24
Java's performance is adequate, assuming that the VM is not a complete POS, and you're not doing something extremely retarded. ARM7 should be enough for anyone

>>25
lol adequate.

>>22,24-25
You're all a bunch of faggots who are just repeating what you've read in some idiot's blog. As someone who's both written software in C for ARM7 and ARM9, and written software in Java for what's essentially a modified ARM9, I can tell you that you're incorrect.

I'm not sure how you think the JVM is implemented on embedded systems, but if you think that C is considerably faster you're a retard. Why, you ask? Why would an interpreted language run faster than a native binary?

Because the ARM architecture has an extension which allows it to run Java bytecode natively called Jazelle^[1]. While I'd argue that for some benchmarks Jazelle is slightly less performant than the equivalent C code (because of how ARM extensions work), it isn't a difference you'll notice as a normal developer.

You faggots should stick to what you know -- instead of bitching about real-world performance issues (which you clearly have no experience dealing with), instead complain about Java's blatent lack of critical language features like closures.

________________________________________________
^{[1] http://www.arm.com/products/esd/jazelle_home.html}

>>27
You're BBCode expertise has convinced me that you know what you're talking about.

>>27
Right, Java just lacks critical language features like good generics. C#/.NET's implementation of generics is superior.

But seriously, you're right. Java hasn't been slow as shit since the early 2000's, but there are still plenty of other reasons to hate Java. My dream is a corporate-sponsored language with C#/.NET's awesomeness with the JVM's portability.

>>29
1. Write a .NET runtime in Java
2. Make it free (NOT GPL)
3. ???
4. Profit!

>>28
You're
I raged like a true aryan whose garden has been trampled on by jews.

>>29
I agree. Java vendors should abandon the language like the sack of AIDS-infested fail it is, and concentrate on running LISP in the JVM

>>32
From what I understand about the JVM that's impossible.

>>33
Would you care to elaborate?

>>34
It's NP-Complete.

>>34
EXPERT PROGRAMMERS please comment but I believe continuations are a bitch to do in the JVM.

Christopher would use Haskell and Software Transactional Memory.<sup>1

1</sup>                        

Newer Posts

---

Don't change these.

Name:		Email:
Entire Thread Thread List