| bio | website | |
|---|---|---|
| location | ||
| age | 22 | |
| visits | member for | 2 years |
| seen | yesterday | |
| stats | profile views | 49 |
|
Mar 4 |
comment |
What is the functional-programming alternative to an interface? You can add sintax highlighting hints when the language in the answer doesn't match the language in the question. See my suggested edit for example. |
|
Jan 16 |
comment |
How can I avoid mistakes using the same variable name again? Honestly, all the 3 answers so far suck. Variable naming doesn't solve this problem in general and puts the blame on the wrong place. Isn't there any linter out there that gives a warning if you assign to a function parameter? |
|
Jan 8 |
comment |
Does the state Pattern violate Liskov Substitution Principle? Basically, the big problem is that object orientation is good for adding new classes but makes it hard to add new methods. And in the case of state, as you said, it is not likely that you will need to extend the code with new states very often. |
|
Sep 22 |
comment |
How to get multiple open-source projects to use a standard way of doing something xkcd.com/927 |
|
Jul 20 |
comment |
If python compiles to assembly and an OS is written in it, will it compete favorably with C in benchmarks? @SK-logic: One might argue that Java is more of a dynamic language when it comes to its implementation though, given how it uses an intermediate interpreter and JIT compiler. |
|
Jul 20 |
comment |
Strategy/algorithm to divide pot to chips What if the cassino is owned by me? mwahahaha! In any case, this problem can also occur in more reasonable situations: for example, if you run out of $5 chips then its better to split $30 into [$10, $10, $10] then into [$25, $1, $1, $1, $1, $1] |
|
Jul 20 |
comment |
Strategy/algorithm to divide pot to chips @Chad: Your greedy algorithm does not work for all denominations. For example, if we the we only have $5, $20 and $25 chips available then the greedy algorithm would split $40 into [$25, $5, $5, $5] instead of the optimal [$20, $20]. |
|
Jul 2 |
comment |
Is this a decent use-case for goto in C? This also works in Javascript. I guess there is one thing where it is similar to Java after all. |
|
Jun 23 |
comment |
Why are effect-less functions executed? @JonStrayer: OK, its my turn tu be pedantic now :) What about for(n=4; is_sum_of_two_primes(n); n+=2){} printf("the goldbach conjecture is false!");? The loop is fully effectless and side-effect free but you don't want to optimize it out and falsely break the news that you found a counterexample to a liong standing conjecture! And just in case you want to say that my point is moot because a sensible person would put the "n" in the printf then I'm not listening :P |
|
Jun 22 |
comment |
Why are effect-less functions executed? @NickC: The hard part is the "provably" bit. While some sorts of effectless while loops are straightfoward to optimize (and many compilers will do so), its easy to get in a slippery slope of properties that get harder and harder to prove and everyone gives up at some point. |
|
Jun 22 |
comment |
When decomposing a large function, how can I avoid the complexity from the extra subfunctions? @Paul: Handling state is a pure FP language is something completely orthogonal that people do all the time. The two main ways to deal with it would a) use datastructure sharing to still be able to use immutable state or b) Use magic monads and the like. The code using state is sequenced and checked by the compiler and under the hood things are just as efficient. |
|
Jun 21 |
comment |
Why are effect-less functions executed? @JonStrayer: You can't optimize away an infinite loop without changing the meaning of the program. What if I had a "fireTheMissiles()" call after the infinite loop? |
|
Jun 20 |
comment |
When decomposing a large function, how can I avoid the complexity from the extra subfunctions? I think I was originally thinking of something simpler problem then the one you are worrying about. Say I give you a module with 10+ functions, how can you determine at a glance if those functions are only sub parts of a main function or if those functions actually implement a clever state machine with 10+ states? |
|
Jun 20 |
comment |
When decomposing a large function, how can I avoid the complexity from the extra subfunctions? We all know that short composable functions are a good goal but we still need to be able to deal with what to do when we have a long list of business logic to follow or a complex algorithm to implement. |
|
Jun 20 |
comment |
When decomposing a large function, how can I avoid the complexity from the extra subfunctions? I don't think this is too different from the version using blocks to separate the subparts (as far as scoping is concerned at least). You gain the advantage I mentioned of passing arguments to the subparts and you avoid the rest of the code from seeing the subparts but there is still the complexity of the subparts being able to call each other that is not present in the undecomposed version. |
|
Jun 20 |
comment |
When decomposing a large function, how can I avoid the complexity from the extra subfunctions? Well, even though global state would make things more complicated this problem also applies to functional languages if you have to do a lot of stuff. I guess going with Haskell style "where" clauses is the way to go. |
|
Jun 20 |
comment |
When decomposing a large function, how can I avoid the complexity from the extra subfunctions? @Ken: Its not always possible to do that though - how do I decompose functions in the general case? |
|
Jun 20 |
comment |
When decomposing a large function, how can I avoid the complexity from the extra subfunctions? @gnat: I think I am dealing with a much more specific issue here though |
|
Jun 19 |
comment |
Why are so many languages passed by value? It could be worse. Some old languages also allowed for call by name |
|
Jun 6 |
comment |
If immutable objects are good, why do people keep creating mutable objects? BTW - even if we ignore the whole mutability vs immutability issue, public getters and setters are a well known source of pain in OO design, since they tend to break encapsulation and invariants. |