The Whiteboard - 2013-01-08

« first day (858 days earlier) ← previous day next day → last day (4126 days later) »

2:30 AM

The last line in this question is really the whole point in my eyes. A developer not trusted will be ineffective at best and hateful of his job at worst. Don't hire people you won't trust. It's pointlessly wasting money on people you won't allow to do the job you're paying them for anyway. — Jimmy Hoffa 5 hours ago

@JimmyHoffa ^^^ Great point.

4 hours later…

user20683

6:02 AM

jpfuentes2.tumblr.com/post/39935683274/…

user20683

D'awwww

8:30 AM

-4

Q: How can I unify multiple ASP.Net projects that share quite a few common aspects?

I have 3 project files, they are all the same project, but used by different customers. According to customer requests I make changes on Web Forms, on ASP, C# or JavaScript parts. Some forms are 100% the same and some are modified, and each project has some extra forms. For the second customer I...

Is this good enough to be re-opened? The original version was crap, but I'm not so sure this one is good enough.

3 hours later…

11:40 AM

@YannisRizos the merge-edit made this question worth re-opening (I voted).

5 hours later…

4:22 PM

Blog - Stack Exchange: Winter Bash 2012 Conclusion: Boxing Day

Aarthi Devanathan on January 08, 2013

So. We’ve torn through the advent calendar, tossed aside all the wrapping paper, and (hopefully) obsessively screencapped our gravatars wearing various kinds of silly hats. As of last Friday, Winter Bash 2012 is officially over!

This event was awesome. We had a total of 46,710 users participating across 76 sites, and we gave away 108,924 hats total. The most common hat was the And I Feel Fine hat, which 23,171 users earned for activity on December 21st. The least common hat earned was I Do Say, which was obtained by Bohemian, on Stack Overflow, and kalina, on Arqade for posting an epic 30 …

user55340

Hmm... @YannisRizos got a photo in there with his cop hat on.

Farrukh Subhani

4:58 PM

Does anyone have issues with jsfiddle in chrome???

Haven't touched jsfiddle

Chrome's built-in tools do the job just fine for me

3 hours later…

8:12 PM

I bloody hate state machines. I just think I identified precisely what it is about them that ticks me off, I think that are basically always a violation of SRP.

user55340

?

A state machine exists to dictate the variety of reasons or rules regarding a state. Even in it's most abstract form where it's delegating those choices to other classes that are singly responsible for each individual check, it's still managing the logic of multiple states

@MichaelT care to tell me where I'm wrong? I just can't get over this sense that the era of the state machine should have been over with the procedural style

And I think I finally figured it out, I don't see how a state machine isn't responsible for more than one thing

or maybe, it's just the standard implementation of a state machine I disagree with

the single-conductor state machine

user55340

Depends on the state machine you are working with. A regex is a state machine.

user55340

For that matter, a vending machine is a state machine too.

I'm referring to the implementation and maintenance of a state machine

I'm not speaking about consumption

further, a vending machine is exactly in the vein I was referring to of state machines having their place only in procedural code

nothing is more global-state than physical machinery

nothing is more procedural

and the implementation of a regex could be done in the decentralized way I'm referring to. Regexp is a concatenative DSL

You could implement it using a single-orchestrator state machine, or using parser combinators that act as a compositional pipeline

user55340

8:18 PM

Lets move a step closer to software then... a cash register. You start out in one state, you start a transaction (sale or return), do stuff, and then go to the tender state (maybe back and foreth) and then start over.

which I guess is a state machine, just nowhere near the standard implementation, so far off it's hardly recognizable as a state machine because it doesn't maintain state

a cash register is still a totally procedurally implemented system

they're written more in assembly varieties or damn-close-to than anything else

(than any other language that is, not than other machines)

user55340

(the one I'm working on is a m[ea]ss of java.

Is it written procedurally, thus the mess?

Am I making any sense at all in my argument for why not single-orchestrator state machines?

user55340

It has almost every pattern and anti-pattern known mixed into one monstrosity of code.

I hear your pain. I started this job ~6 months ago and rapidly got the sense I made a huge mistake. One of the biggest tipoffs was when I used the word antipattern the first week in a meeting with my new team, and no one knew the term

user55340

8:22 PM

The part I work with most closely is the receipt printing, which is its own interpreter (nightmarishly done). How about a class file that is 10k lines long with methods 2k lines long that are of the format if(token.equals("something")) { code } else if(token.equals("somethingelse")) { code }

user55340

here's a few hundred if/else if / else if/ else if/ statements in a chain. Bleh.

user55340

Right now, I'm fixing some rounding problems. Where they mix doubles (big red flag), longs, and BigDecimals indiscriminately.

user55340

But, thats more just me ranting about this code. Though it scares me if I ever see the out of the box register running somewhere... I really think about paying cash only and double checking the receipt.

9:01 PM

few hundred if/else if/else if statements in a chain is procedural code in my head

user55340

But writing an interpreter that way? Each valid token in the DSL as a separate if statement with a block of code to handle it. (When I counted at one point, there were about 900 tokens)

BLECH. that's the procedural approach

hate it.

that's the standard implementation of a state machine that immediately comes to mind for people

Which is why the alternative approach of a composition of combinators is how all workflows should be done, and it is so different from that standard implementation of a state machine as to not really count as a state machine in my mind even though it accomplishes the same task

it decentralizes the orchestration basically

@MichaelT Do you have any idea what I'm talking about? Am I babbling incoherently dictating an irreverence for the long-loved FSM of yore?

user55340

9:16 PM

Some. Though I had to read the last bit twice to figure out if you were a Flying Spaghetti Monster follower.

user55340

I generally find that Haskell programmers do some incoherent babbling. ;-)

I only do the babbling to sound like a haskeller, I can haskell like an infant can walk. That is to say, he's unsteady, and likely to hurt himself if unsupervised.

Really though, the enormous if/elseif chains are something I HATE

they are impossible to follow and maintain etc, they violate SRP inevitably because if you had one responsibility, you wouldn't need that many cases

user55340

I certainly agree. The code is just wrong in so many ways.

and most importantly, there is a solution

instead of having one piece of code enumerating your cases, you have code for each case, and you just tell it where to go for success or failure

regexp's work like that

user55340

I've got half a mind to rip it all out and replace it with jstp jstp.sourceforge.net/manual.html

9:21 PM

[0-9][3-4]HI[a-z] will execute 0-9, and 0-9 is told if success then hand off to the next block the [3-4] knows if success hand off to the next bit and so-on

user55340

Though assuming that the 40k lines of code is what it takes in terms of function, its a several month project... and trying to presuade management to let me go do something for a couple moths that does nothing other than not give me a headache is a losing proposition.

each of the [] blocks could be thought of as individual cases, and would be decentralized to exist in different objects

10:13 PM

state machines are super useful for a lot of stuf

I wouldn't call them a constant violation of SRP

10:47 PM

@whatsisname how do you implement a state machine?

often with an enum and a big switch block

See that's procedural code for one thing, and for another thing those cases are all different responsibilities but that one switch block is being responsible for all of them getting routed correctly

so what if its procedural

a lot of problems are nicely solved with procedural approaches

A lot of problems are nicely caused by procedural approaches as well

namely the problem of maintainable code

Procedural code doesn't grow well over time

neither does anything else

all code bases expand in complexity until they are at the limits of maintainability

its just a fact of life

if something is solved well using procedural code, you are just making your life more difficult trying to avoid just because you have a beef with procedural code

10:54 PM

That's just a defeatist attitude, because nothing is a perfect solution, don't bother choosing the better of two solutions

and I don't find other solutions more difficult, actually I find them easier

the better?

you are simply just saying "all procedural code is bad" it seems

I'm saying all procedural code grows poorly over time, to a significant extent more than other

it's not bad in so far as you use it on tiny projects with no growth expected for fixed growth

for some problems

hardware drivers for instance

for others, it can remain simpler

10:55 PM

do those procedurally, find, hardware that driver supports won't change

Meh, procedural state machines grow poorly over time, does that better illustrate my complaint?

some do, yes

others do not

Constantly arguing one's scenario is the minority where doing something that is usually bad is actually good doesn't really seem like much of a defensible point

If something is usually bad (procedural code in this case) then it's likely it's bad for your case as well

procedural code is not "usually bad"

you are starting from a false premise right there

Ah. Right, the last 20 years of industry learning be damned, the 80's were just so cool

even in 2013, there is still a ton of procedural code being written

11:02 PM

Genocide too, is it good just because it happens?

and stuff like OOP, is more procedural than it is not

you've gotta be trolling

No, honestly I'm not. Just using some hyperbole because you tried to defend procedural code by using "people write it, so it's not bad"

my point being, that's no way to defend any point

and I never said I was an enormous fan of OOP, but good OOP is not that procedural

you have a bias that all procedural programming is evil and that's simply not true, you rambling against it in this chat

and good OOP is still plenty procedural, eventually somewhere you have to do actual work inside all your objects, and thats pretty much procedural programming

just nicely compartmentalized

you also claimed that procedural is harder to maintain than OOP, and that's not necessarily true

both paradigms depend more on the skill of the programmer than what language they use

with respect to how easy or hard they are to maintain

by hating against state machines simply because they are procedural, you are closing the door to useful solutions for real world problems for no good reason

Experience is why I'm knocking state machines

I've seen many start out simple and happy only for them to become terrible over time

as though nothing else suffers the same fate?

11:10 PM

when people see if/elseif chains of death or switch/cases nested in switch/cases nested in switch/cases they're usually looking at the organic end to a state machine

again, that's defeatist; ignoring it's weaknesses because other stuff has weaknesses too

and just giving up on finding a better solution

if/else chains of death are not properly implemented state machines

yes other things have weaknesses, but not all solutions have the weakness of growing into untennable messes

Often times they were properly implemented state machines

yes, all do

ah, apparently you've never seen good code

you must have simply been burned by an especially bad half-baked state machine implementation somewhere and somehow think they are all bad as a resuolt

11:12 PM

I see the problem now, it's hard to differentiate between problems and choose one when you've never seen code that didn't have the problem of growing into death-on-wheels

the only solution that has no risk of growing into an unmanagable mess is to never start working in the first place

lol

no, I've seen many state machines turn that way, and the only ones I haven't seen grow that way were in code for hardware

No one said no risk, risk has a grade, there's more and less risk

state machines have more risk of becoming untennable messes than the alternatives

(except in hardware scenarios where after the code supports the hardware's cases, there will be no more cases so you don't need to worry about code growth)

« first day (858 days earlier) ← previous day next day → last day (4126 days later) »

Transcript for

Jan '138

The Whiteboard

General Discussion for softwareengineering.stackexchange.com P...

coffee-day horror-stories monads my-code-is-compiling scotch the-other-monitor

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile