The Whiteboard

@JimmyHoffa You remind me of when I've faked closures in languages that don't have them, by stuffing the context into some object. It works but by the time you're done it often isn't worth it.

Yeah, the strategy pattern is just a workaround for language deficiencies

Evidence seems to be mounting that Haskell should be the next language I learn.

@JimmyHoffa - Maybe more like the command pattern, since you need to carry your state around along with the code.

There is one and only one negative to it I've found (ignoring the collosal mindf ck the learning curve is) and that's that it doesn't have much reflection facilities because it's not IL

Hmm, the reflection thing is interesting and I haven't heard that before.

Who knew there was something Haskell didn't do :)

And, yes, the learning curve looks a bit steep from where I stand.

1:14 AM

Because the compiler hackers on it are insane smart (though I guess all compiler hackers are) there's some facilities but minimal at best, nothing like people are used to in this day and age of interpreted languages and jit languages

It took about 10 explanations of Monads (maybe 3 helpful) before I could roughly understand what people were talking about. One of the 3 was the Wikipedia definition of Monads in math. The only language that makes me wish I had been taught it at school.

Practically nobody learns category theory in school, I asked two math masters I've known and two Ph.D.s, they all said they heard someone talking about it briefly in a lecture they didn't understand. Only one of those four even knew untyped lambda calc

@JimmyHoffa - Without reflection can you do LISPy stuff like writing self modifying code using Macros in your own language?

@JimmyHoffa - Also, then where did you learn category theory? Do all Haskellers know category theory?

Lol no and i don't, though I'm hardly a haskeler, this has been a year of after work study off and on to get to be able to write monads rationally

Many hazkellers do however seem to know what I affectionately call "crazy math"

If you start to learn it, I'd be happy to help and I'm idling in here most the time (my job assigns very little work throughout the day)

as for lisp macros, those are only truly capable thanks to homoiconicity I think which only LISP and perhaps some other crazy languages can claim. Though the level of abstraction you get with the hindley milner type system in haskell allows similar level of abstraction, just not complete; though more than that you're liable to write your own DSL using monads

monads make any form of state machine insanely easy, which is why I'm writing them in C# right now. Partially to prove a point and learn some to myself that the insane switch/case's with nested switch/case's with nested switch/case's aren't necessary, rather you can compose monadic combinators to create any form of state machine

typically you see people showing this with parsers, but parsers are just one version of a state machine

@psr in regards to your lisp question, this blog I read a while back really shed light for me as to why other languages don't have macros and technically can't calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point the closest you get is interpreted languages using in-line evaluation methods

there are in-line evaluation facilities for haskell as www.tryhaskell.com proves (and I grilled some people about this and they said there are libs that do some of that) but that's hardly a replacement, and it still doesn't give you the reflection ability to enumerate the definition of a method for instance

@psr do you know .NET?

if so there's a fabulous near-haskell clone that compiles to CIL and comes with a simple little set of tools including an IDE that another one of those ridiculously smart compiler-hackers wrote called ela code.google.com/p/elalang

of note: elalang.net/docs/Article.aspx?p=elaandhaskell.htm

I would say it might have a slightly less steep learning curve because it's dynamically typed

(though has no documentation short of the manual written by the language author)

1:37 AM

Many thanks. However, I don't have a lot of idling these days, so unless Enterprise Haskell enters my professional life it may be a while before I get to it.

haha, good luck with enterprise haskell

last I checked that's called C#

C# is about as functional as industry has the stomach for at the "Enterprise" level

Iron Haskell will prove you wrong!

@psr I'll pastebin some code for you tonight to see what haskell simplifies

Ela might be the Iron Haskell heh

I just read down to the ela part of what you said. I guess there sort of is Enterprise Haskell. I'm not currently doing much with .NET, though I have had jobs where I did little else. I don't think I've ever worked in a shop that had enough developers who would be comfortable with it in production code, even if ela was demonstrably mature enough for it.

(which it's not)

perhaps some day

F# and Scala are at the vanguard of functional in enterprise, but Scala is a long ways from Haskell, and even F# is quite a distance in terseness as well as lacking type classes

1:48 AM

@JimmyHoffa - As far as your state machine thing - I know that state machines for real world things quickly move beyond human comprehension, but even without a functional language you don't have to hand-code the state machine. Why isn't, say, a parser generator a solution for you?

Thankyou for standing up for what's right in this world by claiming the truth of state machines! Tired of people telling me "They're great, they don't grow and become terribly harry messes!"

Never touched a parser generator, but can one be used generically for any state machine? Non parser based?

Further, state machines I'm referring to are combinatory making them trivial to alter dynamically

I'm sure it isn't appropriate (even if perhaps it could theoretically be done - not sure about that offhand) for any state machine. But the principle that you could generate the code in a rational way without needing a language with combinators applies.

Not that I'm opposed to doing it that way, but maybe given C# there is an easier way

I've presumed parser generation tools (though I should really play with some now that you bring it up, kind of lame of me to have never touched one) generate the big harry textual state machine for you given a bunch of manual input to define the incoming grammers and the outgoing syntax of the language to generate

Well, like I said; using them is awesome. Writing them they just become vastly expanded compared to their haskell cohorts due to the number of generics and funcs floating about

but you only need a small hand full written to use

@JimmyHoffa - Pretty much. (I actually wrote a parser generator once. Not good enough for anyone to bother using though). They usually do go through some steps to reduce the state machine to the smallest possible form as well. At which point it is really not human understandable.

that's the beauty of combinators I've learned from haskell, a few small atomic pieces can be easily combined like lego pieces to create larger wholes, Linq to collections is the perfect example:

myCompany.Select(x => x.People).SelectMany(x => x).Where(x => x.Title == "Awesome").Skip(perPage*currentPage).Take(perPage);

(that's not real code obviously)

5 combinators in play there which on there own are simple small pieces but combine to create a complete algorithm in a simple way

now think about creating state machines like that through composing functions in that fashion rather than structuring control flow and having to account for scope constantly

2:07 AM

I haven't been spoiled by functional programming languages. I usually think that writing combinators in C# is currently a lot easier than trying to do it with delegates. Or than in languages without closures, where it starts to turn into an ungodly slog.

Anyway, sounds like you have a good solution.

2:28 AM

Yeah, C# is definitely the best solution in industry if you want to do these kinds of things, but like I said, a year now fooling about with haskell outside of work and the terseness has made me annoyed when I try writing code like

public Func<T,U> CreateIt<T,U>(Func<U, U> whoKnows, Func<T, T> whatever, Func<T,U> funcyThing) { return (whatsit) => whoKnows(funcyThing(whatever())); }

having to specify Func everywhere, plus all the generics, and then the => just to create what is in haskell
f x y z = x(y(z))

or rather x(z(y)) heh

Now write me a quick example using .NET 1.1

haha I know, 3.5 is a vast improvement

@psr think about it like this, a year fooling with haskell and writing it in .net 4 feels to me like writing that code in .net 1.1 would to you

moral of the story, maybe don't go learning haskell haha

nah, really though I still love C#

knowing f x y z means x(z(y)) should help me reading an Haskell I happen upon. The terseness doesn't leave a lot of clues.

It's fed me and mine for years now and there's really no room for complaint, half the reason I was able to get anywhere at all in haskell was I had already digested lambdas and linq for years. The poor bastards who try going directly from java to it are probably so lost

haha

2:40 AM

It's true the culture of single letter parameters doesn't get you far as an API consumer

but it gets you surprisingly far as a code reader I've learned

trying to read the C# I just wrote, half the confusion in reading it is you have so much to read and keep track of inbetween the important parts that by the point of executing the code itself following that back is a pain

But I'm still in the air on the single letter parameter phenomenon of the Haskell culture. I was always a huge advocate of very descriptive naming in C# for years

imagine I rewrote the Func delegate as F and then the code I wrote above is written F<T,U> CreateIt<T,U>(F<U,U> x, F<T,T> y, F<T,U> z){ return a => x(z(y(a))); }

which ones easier to read, the one above, or that one?

The above one is much easier for a consumer I would agree

but I think the second version I wrote being terser is easier for a reader

I guess if type comes from structure rather than name you often prefer to see the structure clearly than have a descriptive name

3:20 AM

One of the parts of the haskell culture is implicitness where the consumer is expected to have built a knowledge about things well enough to know what is meant intuitively. For example, a monad type expects 'a' to be the member which is the monadic value, and there's a lot of talk about intuition to just figure on how a data type is structured and what a method means etc

This talks about some of that haskell.org/haskellwiki/Typeclassopedia

For instance there's liftM which will lift a function into the monadic context to be able to work on a monad, but what that function will actually do in the monadic context is described for crap and you just have to kind of intuit how it will play with that monad's rules, and forM and liftA for applicatives forA and countless more

Doesn't seem too far off if you think about it and think about how much intuition you have for how things should work in an OO system, quite a bit really, you just don't think about it

3:35 AM

Step 1 - developers magically develop intuition about Haskel

Step 2 - $$$

I imagine it's really just too hard to explain it all the time without making certain assumptions

user20683

theregister.co.uk/2013/01/16/developer_oursources_job_china

user20683

WAT

5:11 AM

@psr eh, I don't expect to ever develop the "intuition", I think it refers to what academics have after studying crazy math (look at page 3 here homepages.inf.ed.ac.uk/wadler/papers/propositions-as-sessions/… ) for long enough that they can understand things like that just by reading it

that's a document by wadler one of the haskell originators

that people can read stuff like that and have any idea what it means baffles me.

9:51 AM

Hey @gnat, congrats on reaching 10K... Mod tools can be a bit weird, ping me if you want any clarifications.

11:14 AM

thanks @YannisRizos don't know how long it will stay that way - at 10K exactly, there is a good chance I'll dv some crappy answer and get out of that privilege :)

11:26 AM

@YannisRizos you see, not surprisingly I'm on 9999 because of this not an answer "So my big question is: is there a blah-blah?"

11:45 AM

@gnat Question posted as an answer, that's classic forum-itis.

That said, there are traces of an attempt to answer the question in there...

@YannisRizos yup. traces. Until I formatted it from wall of text, it even looked like an almost valid answer

if OP would remove that bloody big question I'd revoke my DV

but the way it is written it looks like asking this question was the main point of posting this

@gnat I went ahead and removed it.

thanks!

by the way the part of mod tools I've seen in my "10-minutes at 10K" looks indeed confusing 0- thanks for warning me beforehand!

You could have done that yourself, btw. Or, if you didn't feel comfortable editing, commenting is always an option...

The most confusing part about the 10K tools is... where to find them.

It used to be the same link with "review". If the last thing you had visited was review, the link was "review", if it was the tools, it was "tools". That nonsense stopped fairly recently. Now you it's a tab under /review.

I see. Yes "tools" I found them. And couldn't figure flag-or-disagree :)

11:52 AM

I never had to figure that out, got my diamond at 8K ;)

@YannisRizos hey you had Teachers Lounge, and training didn't you? they brag about how they prepare new mods all over at MSO :) woo hoo I can see deleted questions. That bloody red bgnd, so far I have seen it only on screen shots and my own self-deleted stuff

@gnat Yes, but the 10K flag tab is useless if you're a mod, we have a different flag handling tool.

@YannisRizos I see. Meanwhile, I did not found one thing I expected - delete votes queue. Am I really supposed to manually walk over stuff that may potentially be deletion-worthy?

Q: Can we get some more review queues - questions with delete votes, recently closed etc.?

@gnat programmers.stackexchange.com/…

Unfortunately it's not queues, just simple lists of questions with delete votes, you can't sort by tags for example.

35

The new /review queues are great, but there are some other lists on the /tools pages that could do with the same treatment. Recently closed questions Questions with reopen votes Recently reopened questions These would be useful to find those questions that need improvement to be reopened or h...

Also the delete vote list is pretty dumb, you need 20K+ to vote to delete questions the first couple of days after they were closed, but it still shows you those even if you don't have 20K.

@YannisRizos thanks! for my current needs, the UI is good enough :)

and I reached my modest daily limit for deletion anyway :)

1:31 PM

@gnat If I'm not horribly mistaken, it's your quote I'm using in the last sentence on this answer. Can't remember where you said it, feel free to edit and add a link.

2:11 PM

@YannisRizos added the link; you likely noticed when we spoke about it recently here (though in a bit pessimistic tone)...

yesterday, by gnat

@MichaelT I thnk I am with you here. Despite **all of my bragging I feel pain every time I get -1 for DVing an answer. I fully understand that this is an "investment into site quality blah blah", but watching 5-10 rep going into the black hole of a regular hot garbage wave once or twice a week is still painful

user55340

4:15 PM

@gnat I glanced at your great wall of text... another resource for you - vance.com/steve/perforce/Branching_Strategies.html

user55340

And then also perforce.com/resources/white-papers/high-level-best-practices

haha, yeah, another resource. That's what he needs.

user55340

Well, was reminded with his answer on a new branching question out there.

user55340

I am in agreement with the role based branching suggested in the vance document and the "branch on incompatible policy" in the perforce document (different ways of saying a similar idea)

4:40 PM

@MichaelT laugh if you wish, but this one is already there, the link under "Best practices in SCM (perforce article)" redirects to perforce.com/resources/white-papers/high-level-best-practices

..I need to check the one at vance.com

user55340

The thing I like about the way that vance addresses branching is that it spells out the roles. The perforce document talks about "policies" but doesn't get into what the policies are.

@MichaelT well the guy appears to be an authoritative member of Perforce community. Article is quite large, I need some time to study it. Thanks for suggestion!

user55340

5:03 PM

The company I worked at before was a huge perforce shop (to the extent that the bug tracking system was a custom p4dti and p4 jobs setup).

user55340

I retain a bit of p4 preference to my personal development and am quite happy with the trial licenses that are provided (20 users, 20 client specs, unlimited files - more than enough for one person)

6:59 PM

I'm generally surprised to see branch management take so much of so many people's time at companies; years ago companies would hire a dedicated resource just to do all the branching/merging (if the company/code base was large enough to warrant) and the devs/leads/etc all really didn't have to care or think about it one bit except when told "Do this work in this branch", or "This bug was detected in this branch, repro it there"

Places I've worked lately (could just be where I've been) have been expecting the whole development org to manage it and it ends up costing a bit of time from everyone. Seems like such a waste.

As @gnat pointed out viscerally, there's enough to it to merit an entire job responsibility of getting it right and keeping it right

user55340

7:35 PM

When I worked at Netapp, there was a build team (about half a dozen people) that were responsible for the care and feeding of the bug tracker, perforce, build scripts... and doing the merging into the RC branch.

user55340

The thing that is important to realize is that developers are best at codding and getting paid to code. Anything else is a distraction from that primary responsibility and job role. Context switches cost time and time is money. Having to go from "I'm thinking about fixing bugs" to "I'm thinking about merging code" costs the time of the context switch.

Yep

Which is why I'm so baffled to see so many companies lately seem to push all that extra cruft off onto devs

user55340

(and the associated Joel blog post on that...)

user55340

joelonsoftware.com/articles/fog0000000022.html

user55340

@JimmyHoffa Read the book Slack... it will make sense as to the idea behind why they are trying... and why it is so wrong.

user55340

7:38 PM

amazon.com/Slack-Getting-Burnout-Busywork-Efficiency/dp/…

add onto that the fact that a dev is doing other stuff and therefore vastly more likely to screw up the merging/branching which effects all developers as opposed to someone devoted to managing that stuff

user55340

A cow-orker of mine loves the bit about secretaries, managers and microsoft word.

user55340

Managers used to have secretaries who wrote documents up for them. But each of them were only at 80% of capacity... we need to be at 100% capacity to make the most money from the time (bad idea, but thats the philos). So use MS Word which makes the secretary's job something the manager can do in 20% time, and get rid of the secretary.

I think the biggest problem is megacorps effectiveness in pushing upwards profiteers who know 0 about software industry and don't care about it, treating it like any other service or producer industry, which it is simply nothing like.

user55340

But that means the manager has no slack to be able to handle changes in workflow and the company loses money in the long term for missed opportunities and inefficent responses.

7:41 PM

software industry is more comparable to R&D

@MichaelT reason that stuff is so pervasive is it actually works in producer/services industries

think about it in the construction industry (producer)

They can work have everyone work 100% capacity 100% of the time

and be effective, because there are no unknowns

user55340

However, when they do have 100% capacity 100% of the time, and something goes wrong... everything suffers.

it's just a matter of step 1 - 843

Exactly!

And things go wrong 100% of the time in R&D industries

:)

Producers have a single right way that is laid out and well detailed, servicers (airlines for example) have a single right way that is laid out and well detailed

user55340

I saw a company building a warehouse. They had the trusses up and accidently bumped it with a crane. Knocked it all down. No slack in the schedule meant they lost significant amounts falling behind in that and all the other jobs that were concurrent.

R&D however (think police detective) have no single right way

@MichaelT true, but that's the minority in those industries

so that minority's inefficiences are absorbed by the efficiences in the majority cases

but in R&D the vast majority has cranes bumping into things

I completely agree with all the points and have read bits from Tom DeMarco here and there

I can't generally stand books. Too expansive, need denser so I prefer blogs

I think the root cause of failures in software industry and general problems is people misclassifying it as construction or services. Think about it, name some successful software companies and think how many of them are managed by software industry folks, people you would expect recognize this is an R&D industry

user55340

@JimmyHoffa You can get that book, used, for $2.20 from Amazon.

user55340

7:49 PM

And new hardcover is only $9.

I love hardcovers. I might think about it, but I really can't stand books heh

user55340

Three times this past year I have gotten Death March, Peopleware and Slack for various management I work with.

The only tech books I own is one Knuth, the K&R, and Crockford. And only Crockford do I ever poke into. I probably still have the Unix Network Programming Vol I. sitting around somewhere from years and years ago

I was thinking about handing my manager something like that, don't want to seem like a dick though

I was pondering starting simpler, some select Joel articles

Maybe in book form she'd feel more obliged to actually read it though heh

user55340

The day after I gave it to a director he asked if I wanted to be reimbursed. My response back was "If it makes things better, I will be well compensated"

True that. I'd be really concerned about being seen as a condescending ass though. Management here is pretty sure they know what they're doing and that they're right.

Imagine if a fresh college grad after working with you for 6 months came in one day and handed you the pragmatic programmer saying "I think this might be helpful"

user55340

8:53 PM

This is more a two decade industry veteran who has been at the company for nearly half a decade too...

A: How to manage a developer who has poor communication skills

9:19 PM

@JimmyHoffa dev is doing other stuff don't you just love management loading developers 30% with support and wondering why they're unhappy? This is true question, asked once here. "hey they have their 70% don't they?"

3

30/70 split may be where all your problems begin. I've never seen developers happy with split like that. I've seen developers being comfortable with 10, 15% other work (and been happy myself because it's fun when the dose is right) but 30% is too much. I'd rather think other team members prefer ...

> 30+70, summing up to 100% productivity when switching between programming and other work, will never happen in real life; it is more likely about 20+50 or even 20+40. Context switches are especially painful for software developers - if you're interested, check this article for a nice explanation of why is that: DON'T WAKE UP THE PROGRAMMER! Programmers who value their productivity would naturally be unhappy about losses like that.