2,820 reputation
1330
bio website
location Argentina
age 38
visits member for 4 years, 1 month
seen 8 hours ago

Software developer and science fiction fan.


Feb
6
comment Relation between object orientation and algorithms
This seems like too broad to me. There are at least 4 separate questions in there. I suggest you focus on only one and remove the rest.
Feb
5
revised In what case a use case should be written
removed irrelevant tag about functional-programming
Feb
4
comment Does it matter how I format the name of a function?
@Den Are you arguing that you shouldn't follow F#'s style conventions when coding in F#? If so, that's terrible advice.
Feb
3
comment What's the benefit of GIT for solo programmer?
I have to side with gnat on this: the OP is confusing git with github, not bothering to look into source control in general and its rationale, displaying unwarranted sarcasm in the question... this sounds like a rant in disguise, and it shows very poor research.
Jan
28
comment Leaving intentional bugs in code for testers to find
+1 It reminded me of that DailyWTF post too!
Jan
27
revised Is the 'finally' portion of a 'try … catch … finally' construct even necessary?
code formatting
Jan
27
reviewed No Action Needed Is factory pattern a right pattern for the situation described here?
Jan
27
reviewed No Action Needed Is factory pattern a right pattern for the situation described here?
Jan
27
reviewed Reviewed Small code, big test
Jan
27
reviewed Approve Is the 'finally' portion of a 'try … catch … finally' construct even necessary?
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Fuhrmanator A customer can still write one-line user stories and business rules regardless of whether you use OOP and FP. I don't expect customers to understand higher-order functions any more than I expect them to understand inheritance, composition or interfaces.
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Doval That's how a Haskeler friend told me to start working on a Haskell function: sprinkling "undefined"s wherever I don't have an implementation yet :) It seems top-down to me.
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Fuhrmanator But you do know where to find a function. And there is only one function, not multiple functions with the same name, defined for each datatype (again, see the "Expression Problem"). For example, for Haskell library functions (which you're encouraged to use, instead of rediscovering the wheel or making a slightly less useful versions of said functions), you have wonderful discovery tools such as Hoogle, which is so powerful it lets you search by signature (try it! :) )
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Den I can't tell what either of those functions do. However, I can tell you if the first function in FP was a sort or a filter, it would be named filter or sort, not func (just like you named it IFilter, etc). In general, in FP you'd name it func or f when either sort or filter is a valid choice! For example, when writing a higher-order function that takes func as a parameter.
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Den The popularity you describe is, I'm afraid, an accident of history. I use Scala at work, and it's a complex beast due to the way it attempts to mix FP and OOP. Switching to a true FP language like Haskell feels like a breath of fresh air -- and I'm not talking from an academic perspective either!
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@BenAaronson That's a very OOP point of view :) With FP, you tend to generalize traversals over stuff, and pass the specific work as a function parameter. In this way, you tend to reduce duplication: there are no multiple ways to do similar things spread over Student, Course, and/or their helpers. AOP seems like a solution to an OOP problem.
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Fuhrmanator True, in the sense you're talking about, both OOP and FP are low-level. But how does this relate to the "representational gap"?
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Den See also Erik Meijer's "'Mostly Functional' programming doesn't work", which argues against the hybrid approach and for going full "fundamentalist" FP.
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@Den Hybrid approaches have their merits. It's not true, however, that the distinction is artificial. There are lots of compromises Scala had to make in order to fit OOP and FP (less powerful type inference is one. Complexity is another: yes, a language that mixes OOP and FP tends to be more complex -- as in "hard to use and understand" -- than one of its purer brothers on the two extremes).
Jan
26
comment Does functional programming increase the 'representational gap' between problems and solutions?
@BenAaronson I find FP more reusable/composable than OOP. Instead of an ad hoc method on a Student class, you have general functions performing general computation whenever you can. Doing some work on a list of Students and returning a filtered result is a typical FP computation that can be applied to almost anything. Why put it in a Student class, unnecessarily constraining yourself? And what if you don't need to give a name to the work you're doing on the Student? Why have a method at all?