Disqus - Latest Comments for tonymorris

Re: Diamond Crash casts Doubt on Incipient Spin Training

tonymorris — Tue, 07 Jan 2020 04:09:32 -0000

FYI, this incident was not near Toowoomba. It was near Jimboomba, south of Archerfield.

Re: What Kind of Things are Easy in Haskell and Hard in Scala and Vice-versa

tonymorris — Thu, 22 Aug 2019 20:29:36 -0000

I agree, today. I didn't at the time of this writing.

Re: Flying Lesson # 46 – 6th Navigation Flight

tonymorris — Sun, 30 Oct 2016 08:12:37 -0000

Nice mate. I've just completed RPL(A) at YBAF. Reading up on PPL now.

Re: 2014 KTM 690 Enduro R to Supermoto

tonymorris — Fri, 20 May 2016 17:11:22 -0000

No mate, mine worked out straight away in that regard. Do you have any photos or video?

My fitment problem ended up being because I;d been sent the wrong disc rotor (990). Only took a year to figure that out!

Re: Why are there no big applications written using functional languages?

tonymorris — Thu, 19 May 2016 20:36:55 -0000

Thank you for your insightful input.

Re: Why are there no big applications written using functional languages?

tonymorris — Thu, 19 May 2016 03:55:29 -0000

80 years ago is when Functional Programming was discovered. I overlooked the "man years" in your question.

I too, have worked on these Java applications. For example, the JDK and J2EE implementations from IBM. They are typically highly inefficient. It is entirely tractable to achieve what hundreds of these developers do in 30 years, in an hour, with appropriate tools. This is why such an inefficiency may not be so apparent.

No, Haskell is not a Functional Programming language. Nothing is, nothing can be.

Re: Why are there no big applications written using functional languages?

tonymorris — Wed, 18 May 2016 23:34:54 -0000

Because of two reasons. Functional Programming was only discovered 80 years ago. There is no such thing as a Functional [Programming] Language.

Re: IO Monad Considered Harmful

tonymorris — Thu, 22 Jan 2015 19:32:03 -0000

I could almost agree. The problem is, this imprecise or ambiguous terminology too often leads to a misunderstanding that is difficult to back out of.

Once we have a decent framework of terminology, where imprecision is perfectly fine and without risk, then by all means! I do this in private discourse where I can be sure that such mistakes won't occur, but in the public arena, whee all bets are off, I get a bit apprehensive.

Your post makes the point where we use "the IO monad" to refer to "nothing at all to do with a monad" -- how often do you see this terminology used, where there is a misunderstanding of this very fact? I see it a lot.

Anyway, the overall point is excellent.

Re: IO Monad Considered Harmful

tonymorris — Thu, 22 Jan 2015 19:23:47 -0000

I do, bat an eye, secretly, inside. Usually because I predict a impending mistake in understanding as a consequence.

Re: IO Monad Considered Harmful

tonymorris — Thu, 22 Jan 2015 19:09:54 -0000

The IO *type constructor*. IO is not a type.

Excellent points though.

Re: 90 Days of Scala

tonymorris — Fri, 09 Jan 2015 18:00:25 -0000

But none of what you listed *are* literal side-effects. They are, in fact, IO effects. Imagine we were talking about [] effects or (State s) effects instead; would we call those side-effects? No, we wouldn't and for exactly the same reason. Side-effects are in no way necessary. There is "modification of global state" that is any different to any other modification of state in other contexts. Does the (:) function modify the global state of the list? No, it doesn't and for the same reason.

Clearly you are learning FP and trying to make an effort and I don't want to discourage that. However, this exact mistake places a huge barrier in front of people wishing to learn and that is possibly the case for you.

No, Scala doesn't force you to do this, but you know what? Many people, who understand FP really well, determined that this was * terrible thing* and wrote the library support for it. That way, we don't have to yield to Scala's mistake in this regard. The result? Enormous advantage.

There is a lot more to this story than the line which has been drawn in the sand in this case. Also, it is way easier to figure these things out on IRC if you are keen.

Re: 90 Days of Scala

tonymorris — Thu, 08 Jan 2015 17:42:39 -0000

None of what you just said is true. Join IRC (chat) and I'll help you understand functional programming.

After that, you can look at your comment and have a giggle :)

Re: 90 Days of Scala

tonymorris — Tue, 06 Jan 2015 18:05:29 -0000

Some of this has been debunked in the 1940s. It's weird how it keeps popping up.

Moreover, the Scala-specific claims have also been debunked, using the vocabulary of Scala. Consider the claim, "Side-effects as a necessary evil", which is just patently false.

Not only is it false in general, but it has been debunked using Scala itself, repeatedly. It is very well-known that I can write *every possible Scala program without ever using a side-effect*. Runar Bjarnason has outlined this the free monad, the Scalaz project has several implementations of libraries that demonstrate it (e.g. ST, IO), the NICTA rng project was built specifically to debunk this claim (by implementing RNG without side-effects) and I am willing to now bet that you are unable to give me any Scala program that I cannot write without side-effects.

This is not a point of pedantry, but of pedagogy. These claims draw a line in the sand with respect to limits of acquisition of knowledge. It says, "this fallacious step is as far as I am willing to go."

Like most people, I bet you are capable of better.

Re: #golang: The next great teaching language - David Huie

tonymorris — Mon, 12 May 2014 00:58:46 -0000

Dear Atanas,
In fact, based on your comment, I can tell that you wear
a clown suit to bed each night. I hope the meaningful of this is
apparent.

Re: #golang: The next great teaching language - David Huie

tonymorris — Sun, 11 May 2014 17:10:16 -0000

Hello David,
Thank you for your response. Please understand that I have used Go, I understand it well and I teach programming too.

I do not intend to pick on you specifically, but I lament this ongoing position, where smart people like yourself have not looked beyond the trash. Go is most definitely not a good beginner language. It teaches beginners that bad ideas are acceptable under the disguise of "compromise."

You can do a lot better. You would be a better person for it. Notice all the complaining about my lament. These are the dunces. You are not one of those. I invite you to do better and I am committed to helping you achieve that. So are many others.

Re: #golang: The next great teaching language - David Huie

tonymorris — Sun, 11 May 2014 07:42:25 -0000

Are you kidding? Seriously, you take this Golang horseshit seriously?

I am just asking because I am sick to death of this constant, sluggish, amateur reinvention of *what we already know to be ridiculously bad ideas*. Go does not have static typing. It has a *broken type system*. Anyone who achieved the mighty level of page 3 of Types and Programming Languages knows this. Honestly, why not aspire to become one of these people? Three pages, that's all it takes. You simply have to be *not a complete dunce* and you have already figured it out. I'm sure all your mates tell you that I am wrong and pat you on the back for pretending that Go is a thing, but I'm just going to go out on a limb here and suggest that you might be smarter than that.

Go's concurrency is redeeming in that it doesn't fuck it up as many of the other rubbish. But that's about it. We already know that is a mistake too. *We already knew this before it was implemented*.

Golang sure as fuck is not a teaching language. Please try harder. I mean, I don't mind a few mistakes, or even a lot of mistakes, but to go absolutely fucking nowhere by praising pathetic language design is just inexcusable. Zero steps. Consider that. It's just disconsolate.

Can we please make an honest effort toward progress? That's all I am asking ultimately. Golang is a fucking scourge, that tricks people like you into thinking it deserves more than the ridicule it invites. Your naivety has been exploited. Three pages, seriously, and you'll transcend it.

Re: Haskell: Creating a sliding window over a collection

tonymorris — Tue, 27 Aug 2013 23:45:11 -0000

The Extend (related: Comonad) instance for [] will help you with your windowed function.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Sat, 10 Aug 2013 18:38:21 -0000

I agree with everything you wrote.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Fri, 09 Aug 2013 17:52:43 -0000

They were chosen exactly as you might think they were. I did not then use them to infer meaning that is as unreliable as asking a lamp post.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Sun, 04 Aug 2013 19:44:50 -0000

That may [or may not] be so, but I am careful not to suggest anything around answering that question.

It is when we pretend that we can infer meaning with "meaningful identifiers" or other such nonsense that start our journey of peril.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Sun, 04 Aug 2013 19:24:40 -0000

I contend that the extent to which you pretend this mnemonic is
useful for inferring properties about the function is the same extent to
which you are making errors. I don't believe you (anyone) pretend this
mnemonic is useful anywhere near as much as is alleged.

It isn't
useful, not a single bit, in the given context — to infer properties
about the behaviour of the function. I can test this even on the most
vocal and ardent subject and watch them stumble at a rate equivalent to asking a lamp post.

I really mean, "not at all" and I think this is generous. I am not even taking into account the penalty of believing otherwise.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Fri, 02 Aug 2013 00:16:53 -0000

It is true that this type is multiply-inhabited. It is not true that therefore, identifier names are helpful.

I am not sure why this point was missed, given that it is a good portion of the article.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Thu, 01 Aug 2013 05:10:11 -0000

I agree. I had a couple of interpretations of his comment and the one you allude to I had already addressed below. I explicitly address the concern expressed in the article.

I had second thoughts about this interpretation (did this person really just not bother reading, or did I misinterpret?) and I decided to cover both bases with an alternative interpretation, however less likely it might be.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Thu, 01 Aug 2013 02:57:43 -0000

More specifically, the answer given by Donny is incorrect, since it would not have type-checked. In other words, I know for certain that Donny could not give me a program that says what he thinks it does, with his given type.

It is the fact that I do not have to trust Donny to know some important properties about the function. The reason I do not want to trust Donny is because he tells lies (mistakes). Exactly as he did here. If Donny told me he has a function of the type `[A]List[A] => List[A]` and then he said, "it does rot13", I would tell him, "No it doesn't, you are lying" and I could do that confidently.

More strongly, if Donny said he has a value of the type [A]List[A], but he refuses to reveal to me which value that is, I don't need to negotiate with him. He has the `Nil` value, since no other value is possible. That is to say, no I don't give up and in fact, I can tell you that all of Donny's values are precisely the same without knowing anything more (and ignoring Donny's mistake). I thoroughly enjoy this degree of confidence, reliability and independence from Donny's tendency to err.

In short, Donny proved the point quite well, even if inadvertently.

Re: Sticks and stones may break my bones, but names will never concern me

tonymorris — Wed, 31 Jul 2013 23:31:09 -0000

Sorry, let me rephrase.

Unfortunately, an implication of the halting problem, in a turing-complete environment which I have [bravely] assumed, is that we cannot prove these program properties, for the general case. This does not mean we cannot prove some program properties in those environments, or prove all program properties for a given (non-turing-complete) environment.