Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 25 26 27 28 [29] 30 31 32 33 ... Last
[#] Tue Oct 10 2017 21:22:59 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


^^^this++

[#] Wed Oct 11 2017 11:58:31 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


This is why I prefer C++.

*evil grin*

[#] Fri Oct 13 2017 18:11:17 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


It's people like you what cause unrest.

[#] Tue Oct 17 2017 11:09:36 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Oh, it's especially fun to read these in the text client in reverse order.

[#] Wed Oct 18 2017 16:47:34 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


""const considered harmful" considered harmful" considered harmful. (Don't make me bring Godwin in here.)

[#] Wed Oct 18 2017 17:43:51 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


STFU and code.

[#] Thu Oct 19 2017 09:56:22 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Did that... created an executable that waits on your Windows domain controller to change its network settings before changing the workstation network settings (and renaming the hostname), because things go wrong if you don't do this sort of thing in the right order when you're 'randomizing' your network settings.

This job has me do some pretty strange things.

[#] Mon Apr 02 2018 16:41:04 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


*grumble* Fucking multithreaded programming. Easier said than done...

[#] Mon Apr 02 2018 19:02:12 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


Everyone says, "Why? It's easy!"

No. It isn't.

It is always a deception waiting to bite you in the ass someday while your customer breaths down your neck for a solution.

I try very hard to avoid multithreaded programming, or to recast the programming in asynchronous terms instead, so while the logic might feel dysjunct, at least most of the problems associated with true multithreading are mitigated.

[#] Mon Apr 02 2018 22:44:21 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


That wasn't an option here, we're required to do some resource pooling stuff that isn't available off the shelf.

[#] Tue Apr 03 2018 09:49:25 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


I get it... sometimes, you're forced into it. And it's never easy.

[#] Tue Apr 03 2018 13:43:39 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Heh. I remember our old friend Mr.T used to say that about a lot of bad design decisions. "I got railroaded into it!"

[#] Fri Apr 06 2018 18:44:22 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

The thing is, if your code is built for event-driven asynchronous architecture, it's already **mostly** multi-threading ready. The only thing you need to worry about then is shared resource locking, which can be made easier by wrapping shared resources in a server process (in the Erlang sense of the term "process", not Unix-style process!). The complexities that everyone always complains about invariably involves POSIX-style thinking (which both Windows and POSIX-based environments use), which eschews the rigor of message passing for locking things willy-nilly.

[#] Mon Apr 09 2018 10:26:10 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


Agreed.

Much easier to think about things in terms of asynchronous message passing than locking resources.

The locking resources approach is heinous, and mostly what I'm talking about when I say that multi-tasking is hard.

In C++, the asio library makes handling this stuff much, much easier, as it provides a very nice environment for what you've described.

[#] Mon Apr 09 2018 13:32:41 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

"event-driven asynchronous" sounds suspiciously like a state machine.

Please tell me you aren't praising state machines.



[#] Mon Apr 09 2018 17:05:34 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

I am. Computers are state machines. Objects (in the object-oriented programming sense) are state machines. Functional programming is, when you separate state from the combinatorial computation that FP is famous for, all about state machines. Monads (in Haskell, O'Caml, et. al.) are all about managing how state machines are built. Programmers invariably get into problems when they start thinking in ways that, at its core, doesn't have any relationship to states. What do all these different methods have in common? They're different notations and tools to help programmers manage state transitions.

[#] Mon Apr 09 2018 18:49:06 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

<oblig>

 Dec 5 2001 5:26pm from LoanShark
state machine!
state machine!
o how i love thee

state machine,
state machine,
so intertwined

state machine,
state machine,
better than spaghetti

state machine,
hate machine
who the hell needs localization anyway?

state machine,
shmait machine!
screw this, i'm getting into real-estate



[#] Mon Apr 09 2018 20:38:59 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]

2018-04-06 14:44 from kc5tja @uncnsrd
The thing is, if your code is built for event-driven asynchronous
architecture, it's already **mostly** multi-threading ready. The only

thing you need to worry about then is shared resource locking, which
can be made easier by wrapping shared resources in a server process (in

the Erlang sense of the term "process", not Unix-style process!). The


I feel like that just moves the problem somewhere else. Dealing with shared state always has complexities. For example, one of the problems I was dealing with was not so much locking-related, as it was a mistaken idea that we could delete something from the shared state, a little too early...

[#] Mon Apr 09 2018 20:40:32 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


Thanks IG, I wouldn't want to quote myself ;-p

[#] Tue Apr 10 2018 01:13:33 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Even worse, I discovered that my "classic posts archive" has been lost and I had to go to the WayBack Machine to get it. Unfortunately that also means I've permanently lost anything added to the archive since 2009 or so. :(

so yeah, I'm not really a fan of event-driven unless the application naturally fits it (like answering UI input events or responding to HTTP queries). I know some people like to turn every program into one big event loop, and although I respect their mad skillz, I find it makes the program unreadable.

Go to page: First ... 25 26 27 28 [29] 30 31 32 33 ... Last