2,292 reputation
619
bio website
location
age
visits member for 2 years, 6 months
seen Apr 14 at 11:10

Senior Software Engineer and Software/Infrastructure Architect.

Linux/Unix fan and Schemer.


Apr
13
comment Pattern matching against two similar types
The missing type is absolutely the best answer, @MI3Guy. It offers the simplest, clearest, safest code.
Mar
24
comment Why do you need higher kinds?
Scala has type classes. They are implemented with implicits. The implicits provide the equivalent of the Haskell type class instances. It's a more fragile implementation than Haskell's because there is no dedicated syntax for it. But it was always one of the key purposes of Scala implicits and they do the job.
Mar
23
comment Why do you need higher kinds?
Been too busy changing jobs but finally will find some time to write my own answer. I do think you've been distracted by the idea of constraints, though. One significant aspect of higher kinded types is that they allow functions/behaviour to be defined which can be applied to any type which can logically be shown to qualify. Far from imposing constraints on existing types, type classes (one application of higher kinded types) add behaviour to them.
Mar
17
comment Why do you need higher kinds?
Casting isn't an appropriate analogy. What is done with type classes (or similar constructs) is that you show how a given type satisfies the higher kinded type. This usually involves defining new functions or showing which existing functions (or methods if its an OO language like Scala) can be used. Once this has been done, any functions defined to work with the higher type will all work with that type. But it's much more than an interface because more than a simple set of function/method signatures are defined. I guess I am going to have to go and write an answer to show how that works.
Mar
17
comment Why do you need higher kinds?
@supercat It is not about duck-typing. That's a ridiculous thing to say about rigorously typesafe languages like Haskell and just shows you really haven't grokked the concept. Higher kinded types simply provide a high level of abstraction. As necessary, you refine the high level abstraction by adding more detail, in an interative design process. Really, go read the linked question, go read the links they provide, maybe try out the concept in a language that supports it. Stop throwing up reactionary insults defined by what you are familiar with. That isn't how to learn.
Mar
17
comment Why do you need higher kinds?
@supercat You are entirely missing the point. Type classes do not require a shared dependency. They provide a way of arbitrarily placing one type into a larger group without any modification of the original type and with no need for type-specific code in the larger abstraction. You're too close to the OO trees to see the more abstract forest. Code written to work with a higher kinded type also has no dependency on the lower, more concrete types.
Mar
17
comment Why do you need higher kinds?
There are several good answers here: stackoverflow.com/questions/21170493/…
Mar
16
comment Is Functional Programming a viable alternative to dependency injection patterns?
This question, the articles it links to and the accepted answer may also be useful: stackoverflow.com/questions/11276319/… Ignore the scary Monad word. As Runar points out in his answer, it isn't a complex concept in this case (just a function).
Mar
14
comment How do you iterate through an array and delete an element?
Well, depending on the usage pattern (how often you change the dataset and in which way), simple arrays really may not be appropriate. Between my answer and @MichaelT's, I hope there's some help. One important thing to consider: copying to a new array means any reference to the old array will not see the update.
Mar
14
comment How do you iterate through an array and delete an element?
Fair enough but I do think the OP's question implies a basic misunderstanding or misuse of arrays which needs specific addressing if true. But I've my own answer for that so no worries.
Mar
14
answered How do you iterate through an array and delete an element?
Mar
14
comment How do you iterate through an array and delete an element?
How does this answer the actual question? I realise it is a naive question, but you're providing general knowledge which might improve his general understanding of Java collections while still leaving him to grope for the right answer. It really would help to give a specific answer either based on this extra information or preceding it.
Mar
14
comment How do you iterate through an array and delete an element?
How often would you want to do this? Java arrays are fast for a small set of operations and slow for others. They are most efficient when the contents are constant in size and predictable in the location of any desired value. If you often want to remove elements, you may be better off with a map. If you often iterate over the array to find a particular value, you may be better off with a list (or map). If you want to store values at constantly predictable locations but may or may not store a value, then you could use objects rather than primitives, allowing null (but map would be better)
Mar
12
reviewed Reviewed Why am I getting field visibility warnings in Sonar?
Mar
12
reviewed Reject Why JavaScript? What's the advantages?
Mar
12
comment How are objects modelled in a functional programming language?
@Izkata Excel would represent a special case of dataflow programming: reactive programming
Mar
11
comment The dream of declarative programming
Oops. Sorry Hyde, those comments were for @jamesqf
Mar
11
comment The dream of declarative programming
Your opening paragraph seems to be an answer to a point in arnaud's answer programmers.stackexchange.com/a/275839/67057, not to the question itself. It should be a comment there (on my screen, your answer is no longer below his, for one thing). I think the rest of your answer is an illustration of how a small amount of declarative code could generate a large amount of equivalent imperative code but it isn't clear. Your answer needs some tidying, particularly with regard to the salient points.
Mar
11
comment The dream of declarative programming
The important point is that in declarative languages the high level abstractions are meaningful and apply constraints which force implementation to honour the intent. Imperative OO languages can only simulate that kind of abstraction, with tests being the only (very inadequate) proof of correctness.
Mar
11
comment The dream of declarative programming
But to answer your main point, declarative languages can allow a very clean separation between definition of a type (data or a function) and the implementation. In a declarative functional language, you would still be defining various efficient sort algorithms, but those would be somewhere else (and entirely ignorant of any types you define). In yet another place you would map sorting algorithms to types for those contexts where sorting is required. In a logic language, otoh, you would iteratively refine your definitions to approach better performance.