|
You certainly confused me with "flip one off" never heard of that one 
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
You've not heard of "flipping someone off" or "Giving him the bird"?
I'm surprised.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: "flipping someone off" or "Giving him the bird"?
I had also not heard of "flipping someone off"; it actually raised a somewhat odd image in my mind  . But "giving the bird" is, I think, an Americanism that is not that common over here.
|
|
|
|
|
No not heard of either, it might stem from the fact that I don't watch telly
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
Been learning F# through the MS F# reference source but it seems very contradictory in some areas and devoid of meaningful explanation in others. I found the F# foundation site which has some good reference material but I was curious if anyone here has a good book recommendation from their list or elsewhere? I'm the type that wants to know exactly what something does and why it's useful, not just told to use x in situation y, and unfortunately in my experience a lot of tutorial-type books tend to avoid those more difficult questions.
For example, I'd love to figure out why type Class6<'T when 'T : (member Property1: int)>=class end is used as a legal example of a generic in the MS F# reference source when that same documentation says member constraints can only be used with statically resolved type parameters, not normal generics. Or why structs are even a thing in F# considering struct records accomplish all of the same things, PLUS they play nice with type inference in situations like pattern matching where normal structs require a when clause. 
|
|
|
|
|
Jon McKee wrote: Or why structs are even a thing in F#
The same reason you have byrefs and other "strange" things... interoperability with .NET ecosystem and to obey CLS/CTS.
modified 9-Sep-21 5:50am.
|
|
|
|
|
Yea, I'll have to dig deeper into this because it seems like struct records are just a strictly better version of a basic struct. You can still use the IsByRefLikeAttribute too. It probably will end up being some edge-case interoperability like you mentioned 
|
|
|
|
|
As for a book, I doubt you'll find one that go into more bizarre language details. I read Expert F# [Apress] and Programming F# [O’Reilly]. I enjoyed the second one better, but seems like there are no newer editions which would cover more recent versions of the language.
|
|
|
|
|
I'll check those out, thanks! It doesn't really bother me if the book is a bit outdated as long as it's good. I can always go through release notes to see what changed 
|
|
|
|
|
I suppose you already found this excellent site: https://fsharpforfunandprofit.com/
It not only covers the language, but also many concepts.
I read big parts of it when I was commuting by train (in Belgium that gives you sometimes more time than you planned  )
|
|
|
|
|
Gaston Verelst wrote: I read big parts of it when I was commuting by train (in Belgium that gives you sometimes more time than you planned )
I hope you read the 'railway oriented programming' parts on the train...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I did, it gave me a bitter-sweet taste
|
|
|
|
|
The two F# books I have (which seem pretty good) are Essential F# and Domain Modeling Made Functional, which is by the same gut (Scott Wlaschin) who's produced the F# for Fun and Profit website mentioned elsewhere.
As for the bits of jankiness where F# and .NET collide...well, when you friction weld a functional first language like OCaml with an OOP first VM as in .NET, you get some mess at the boundary...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I wasn't aware F# was based on OCaml (never used it but heard about it). Looked up the syntax and yea, I definitely see the inspiration.
|
|
|
|
|
I was reading this great article[^] on CP and it got me thinking:
Isn't SDLC and Agile rather orthogonal, even in opposition with each other?
And I suppose DevOps is sort of one piece of both, but possibly also in conflict with both?
What do you think? Are these "cult-ologies" compatible with each other?
|
|
|
|
|
I suppose Agile is a series of Micro-SDLCs.
DevOps is a meaningless buzzword.
|
|
|
|
|
SDLC can be used as an overarching plan for the Agile development process, so long as you're willing to review both in light of new information and user needs. The fundamental weakness with SDLC is it doesn't handle requirements changes well. The fundamental weakness with Agile is the general lack of overall lifecycle thinking.
|
|
|
|
|
Yeah, we just went to a weird flavor of agile and I've been clearly told that there is nothing but user stories. There is no overall design. I don't see it as a good thing, but that's not my problem ... or apparently anyone else's.
|
|
|
|
|
I've never had a high opinion of any of the formal software methodologies or their promoters. They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
My group has run into this quite a bit, since we are a software group embedded in an engineering/R&D organization managed by mechanical engineers. The M.E.'s seem to be very fond of highly-detailed procedures for managing hardware development. I can see where these things work for them, but they're rarely applicable to software.
At the moment we're fairly free of this nonsense. As long as we produce, they're leaving us alone.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
Actually, I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT.
DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC.
We'll soon be back to the days of hacking code on Production, with no spec! I remember them well - the 'good old days'! 
|
|
|
|
|
No question but that management fell for it.
|
|
|
|
|
I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Software Zen: delete this;
|
|
|
|
|
|
Gary Wheeler wrote: I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Ahhhh, the 'real' Agile Manifesto:
We value:
- Repeated mantras over proof of benefits.
- Certification over knowledge, experience and talent.
- Blind acceptance over a questioning mind.
|
|
|
|
|
Actually, it's a really tough problem to solve.
How do you run a project that is part Artistic (requiring creativity), and Scientific, testable, repeatable, and educates the stakeholders as to the importance of their interacting and being available to the tech team trying to solve their problems?
Also, how do you prevent "cave dwelling" coders from hiding in their caves, coming out with something they thrust on the users, based on what the users asked for?
Having been around the industry for decades, and dabbling in management (but was a strong coder). I can see both sides. Furthermore, how do you manage this, when the complexity is huge?
And how do you get consistent results?
I don't think it was a grift, I think it was an attempt to COMMUNICATE the situation. The reason?
Because we ended up developing our OWN version of XP as a natural approach to these problems. I found that Agile did a great job of codifying/naming the problems. But, we only used pair programming for training. We used code reviews over TDD (We limited testing code to class/libraries).
While I saw some benefit to refactoring and TDD (and how it forced you to think FIRST as a CONSUMER of the functions, then the creator, but we did that naturally)... I could not justify the extra time/energy on all the test code. Leaning on code reviews was correct for us.
Finally, we PUSHED the concepts of "Points of Contact" with business, and the REQUIREMENT that they be available, and that they be allowed to make decisions (oh the pushback. They wanted Jane to answer our questions, but not be able to decide without 5 meetings on every decisions, in case she had it wrong).
I feel Agile helped the business people understand. You cannot withhold required information/decisions and demand we KEEP our deadlines!
It's tough. There are a lot of decisions. There are a ton of impacts, and a lot of risks. Besides that, the developers were usually expensive resources to tie up.
I can't blame anyone for working towards making it better than "Tell us what you want, and we will get back to you when we are done!"... LOL
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
