@hiredman I agree, but remember that the input of the top of the transducer chain is dependent on the output of the last step of the previous iteration of the chain (the reducing function).

Imagine a transducer chain where the acc switches from string to int to string and back. It's not good enough to say it's Union[string, int] because it's only ever an int if the previous iteration was a string

the cat transducer would be (X -> Y -> Z) -> (X -> [Y] -> Z) for example

again, I think that is somewhat spurious, you start off asking "how can you represent transducers" and have jumped to "how can you represent state changes" (or linear types, or whatever it would be called, I am not a type guy)

Yeah, I think that’s the issue though. And what rich has implied on several occasions. Getting something transducer-like is easy. Getting all the aspects of transducers is hard (if not impossible) in existing type systems.

And so at that point I kind of stop car

*caring

that is a facile argument. types are there to limit the ability to express incorrect things, vast swaths of the behavior of untyped transducers allow for would be considered incorrect under most circumstances.

the question is how much you gain by cutting off access to those weird corners

The problem is though that these types artificially limit correct transducers, for little benefit.

do they?

when was the last time you wrote a transducer that switched types of the accumulator?

A few months back, a statistics gathering reducing function that would vary the type of the accumulator depending on the statistic size

do you think you wouldn't able to model that as some kind of ADT?

But I admit it’s ra

wow, I can’t type

*rare

again, I am not a type guy, but that sounds like a candidate for haskell type classes(or clojure protocols)

so the type is some abstract thing that you interact with via some interface that might have different representations

But for me that’s the problem I all I ever hear on Reddit, blogs, HN, etc. is “I’m not a type guru...but....it should be possible”.

because you hang out in dynamiclly typed places

There are some languages that attempt Clojure-like semantics with typing (to bring this back to the OT), but none actually pull it off

I was saying Haskell Reddit, etc.

I think that has more to do with people not actually understanding the entire semantics of most clojure constructs

all I see are straw men on both sides, and of course the reaction from the otherside is "oh, that strawman isn't actually the thing I use"

A transducer has three arities, so it's more complex than (X -> Y -> Z) -> (X -> [Y] -> Z) (to pick on the example above).

Heh yeah, the whole multi-arity thing in Haskell is problematic

And then there's reduced to consider as well -- since any reducing function can produce that.

I saw a Haskell transducer implementation recently that got close to the right semantics, but it did so via tailcalls, continuations, and state monads, and about half way through my Haskell fu failed me.

(given that Haskell functions always take exactly one argument, how do you even model a niladic function?)

Also I think they handled reduced via some sort of interpreter dispatch. Return :reduced if done, return :continue to continue to the next step.

that is generally how the iteratee stuff works

@seancorfield I saw an example of that in F# recently, but it wasn’t standard ML I think.

the other thing I think is, who cares if you can represent transducers? do they intrinsically have value? no, they have value as a solution to some problem, does the typed world have their own set of solutions to those problems? generally yes. so does it matter if you can represent something from the untyped world?

No, of course. But my interest in this area is somewhat selfish and political. I get tired of having to defend dynamic languages as somehow being a sub-par language. Being viewed as a coder of “unsafe” programs. And that’s something I have to actively combat when working with some clients.

So I appreciate finding aspects of dynamic languages that are simpler, and more natural than corresponding aspects of static languages

Yeah, having folks bandy around "unethical" about "non-statically-typed languages" tends to cause division...

Because I'm a masochist... learning Kotlin and wrote my first unit test with KotlinTest... running it via Clojure (of course!):

boot -d seancorfield/boot-kotlinc -d io.kotlintest/kotlintest kotlinc -k src/kt -k test/kt call -p -e "(import '(learning SumTest) '(org.junit.runner JUnitCore))" -e '(bean (JUnitCore/runClasses (into-array Class [SumTest])))'

No need to install anything. Just write my src/kt/hello.kt and test/kt/hello.kt files and compile & run the tests ... so easy! 🙂

I agree that the comment made about ethics & un-typed languages is problematic (to put it mildly), however, I dabble in both worlds, and it is infuriating when ppl on both camps start yelling at each other. These are just tools to get the job done. We don’t get into religious battle about what brand of fork we use when eating, why do we have to fight over type vs un-typed. They are tools that allow us to find solutions to problems, sometimes in different ways.

I was in a brief project using Ruby with a teammate who resisted dynamic languages pretty strongly, mostly due to prior experience with JS. Was able to demonstrate the pros and cons of following Ruby's approach, showing when dynamic typing provides alternatives instead of merely removing or adding things. Where you have to work harder to assure some properties, other properties come easily. It all came down to the ability to reason about what was going on, for us, and the 'comfortable subset' of Ruby ended up feeling a lot more stable than the 'comfortable subset' of JS.

I'm all for the pros/cons approach, and I think that's the best way to go about it. The problem is when any approach reaches the level of dogma. That was the case not too many years ago with OOP. You couldn't find a job, or start a project in a language that wasn't OOP. I really don't want to see that with type systems.

Yes, I agree, I’d hate to see another one of those OOP-style dogmas that took over the industry. I feel like it kept the industry back because it didn’t allow us to explore and try new ideas. That is why I also dabble in both typed and un-typed languages. Because both have lots of concepts and ideas to teach me. And there are brilliant minds on both sides. When we lock ourselves up in one camp and start having these flame wars, it only keeps us (and future generations) back.

For example, although my first languages were C and Java, I built my first real project using PHP when I was a student. And used it for a quite a while. But I also fell in the wrong crowd and bent to peer pressure and started to have contempt for PHP. Mostly because I bought into the OOP camp and since PHP didn’t support OOP, well, it was deemed a sub-par programming language. But when I look back, it was very simple, and I was able to pass in functions, and return functions. By removing all the complexity of OOP, it did offer some valuable lessons, that we just threw away for years because OOP was king. And that sort of attitude still exists today within the wider programming community. We look down our noses at different languages because it doesn’t fit within our mental model of what the best language should be.

There's a difference between discarding imperfect in pursuit of perfect and identifying languages with deep flaws that work against your ability to model any system will, such as PHP and its incessant inconsistency.

Languages have always fascinated me. I learned programming as a teenager using calculators (Sinclair, then TI-58) and my school ran an optional correspondence course in Algol 60 (turnaround time on your homework was one week!). At university I learned about a dozen languages and my final year project was to write an APL interpreter (in Pascal). Then I did PhD work on FP languages. Then got a job at a small UK compiler company. So I've developed strong opinions on language design -- and I love some languages and detest others, mostly due to syntax rather than semantics 🙂

I have a running theory that people in the industry: 1. See learning new languages as being the most difficult task one could take on, especially if they only know one language deeply to begin with 2. See old 'dead' languages such as Lisp, Prolog, and Smalltalk as wastes of time because they are not widely used instead of examining why they were made and why they were shunted aside For those reasons, I push those around me to consider and try new languages, any new languages, especially in paradigms unfamiliar to them, because oftentimes that lifts them up by an order of magnitude in understanding software as a whole, and in seeing the tradeoffs available to them.

I'm a TA for the online version of Univ. of Washington's "Programming Languages" course that uses Standard ML, Racket, and Ruby to illustrate various aspects of language design and I'm no longer surprised (5+ years into doing this) that students always ask "Why should I learn SML/Racket when they aren't used in industry?"

Not surprised, but still depressed 🙂

I went through that very class, and it's what sold me on Lisp and FP.

I think it's a great course! I took it initially as a student back in 2012 I think and I've been a TA/mentor in every single run of it since.

It is odd that the schooling for CSE has placed such a sharp divide between scholastic software and applied software, though, especially when not in the context of a trade school.

@fellshard What would you pick in place of SML and Racket -- given the teaching objectives of that course?

we had a nice PL class with a scheme metacircular interpreter, smalltalk and snobol4 of all things

I don't know that I would! Maybe some things more out of the ordinary instead of Ruby - Forth, Prolog, or one of the array processing langs that doesn't require special charsets

Smalltalk is hard to do these days, though I'm finding Pharo to be a reasonable starting point

we had to abandon our occam project because there werern't any 64 bit compilers

Occam... That takes me back! I sat in on CSP course at uni (run by a different department, so it didn't count for my degree). And one of my jobs in the early 90's was to write a transpiler targeting Parallel-C for the Transputer (source was a somewhat arbitrary "actuarial formula language").

I took that coursera course too, and it is how I fell in love with SML. I had so much fun with it.