8 ms·

I'm so happy powerful type systems are more popular now. TypeScript bringing a great type system to a language as popular as JS is fantastic. Rust is also a gre

• dreamer7 5y ago
  Could you point to any good resources on this topic?
  • ebingdom 5y ago
    The standard reference, if there is one, is Benjamin Pierce's "Types and Programming Languages" book.
• marginalia_nu 5y ago
  The grass does seem tend to appear greener in the other paradigm. Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Writing anything nontrivial with duck typing made more elaborate type systems seem appealing. Needing a PhD in category theory to produce a side effect will no doubt make some other paradigm seem appealing in the future.
  • shepherdjerred 5y ago
    You don't need a PhD, you just need the first few chapters of [Category Theory for Programmers](https://github.com/hmemcpy/milewski-ctfp-pdf https://github.com/hmemcpy/milewski-ctfp-pdf) :)
  • ebingdom 5y ago
    > Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Eh, I consider Java to be barely typed too. If you have a variable of type Foo, the type system doesn't even guarantee that you have a Foo in there (it might be null). The whole point of a type system, in my mind, is to guarantee that I have that Foo! > Writing anything nontrivial with duck typing made more elaborate type systems seem appealing. In my mind, this makes type inference seem appealing, not duck typing (which is not well-defined, but most people associate it with dynamic typing). > Needing a PhD in category theory to produce a side effect will no doubt make some other paradigm seem appealing in the future. This oft-repeated exaggeration needs to stop. Using monads does not require a PhD in category theory. If you can understand Promises in JavaScript, then you can grasp how IO works in Haskell.
    • throwanem 5y ago
      I'd love to see an explanation of monads that accurately captures their capabilities in terms no more complex than those required to do the same for promises.
      • jmfldn 5y ago
        Monads are chainable containers for a computation. The container represents some sort of "effect" implicit to the computation ie asyncrony, optionality etc. This is not technically 'correct', monad explanations are always a bit cursed, but I find this a pretty useful intuition to work with day to day.
      • goto11 5y ago
        Monads are a pattern for function or method chaining.
      • Choc13 5y ago
        I had a pop at this here https://dev.to/choc13/grokking-monads-in-f-3j7f https://dev.to/choc13/grokking-monads-in-f-3j7f
  • nicoburns 5y ago
    > Needing a PhD in category theory to produce a side effect will no doubt make some other paradigm seem appealing in the future. I think it’s only really Haskell (and perhaps languages like Idris) that’s super strict on side effects. In Rust it’s a simple mut annotation, and perhaps a mutex (and you’ll want that in C too of course) if you’re working across threads.
    • knuthsat 5y ago
      Does rust have Mut annotations on functions? I mean, when you look at a problem that monads solve with types is that every function has an “annotation “ of what it uses (IO or mutable state). Similar how async in JS allows await, a state annotation would allow put get or IO annotation any of the IO capabilities. Of course monads are much more but Mut does not look like it pollutes everything with Mut, including function definitions and results
      • lalaithion 5y ago
        No, it does not.
    • whimsicalism 5y ago
      Effects systems in Scala
  • dllthomas 5y ago
    I think the major shift was that originally types were used mostly to talk about representation. Then we wound up in a situation where caring that much about representation didn't make sense as often (at this point it's at system boundaries and when we care an unusual amount about performance) and so it made sense for some languages (covering a growing portion of programming) to stop talking about representation. But it turns out there are other useful things that we can use similar technology to "talk about" as we learn to build better tools and to better apply them.
  • kazinator 5y ago
    C is not "barely typed". It has quite a lot of type checking. An expression like "obj.memb" in C requires obj to be declared to have a type which has a member "memb". C catches it if you call a function with the wrong number of parameters, or wrongly typed parameters, such as passing a "struct foo *" pointer where a "struct bar *" argument is required. C has "holes" in the static safety net in areas like memory safety: object boundaries and lifetimes. It allows some unsafe conversions, like any object pointer to a void * and back. But not only those: C has unsafe numeric conversion and operations. Still, there is a type system there, and C programs greatly profit from it; it's the big reason why we have so many lines of C code in our computing infrastructure, yet the proverbial sky isn't falling. (Just the odd lightning or hail here and there.) C compilers also help; modern compilers have a lot more diagnostic power than compilers thirty years ago. In C, it is critically important to diagnose more than the bare minimum that ISO C requires. For instance, whereas a function that has not been declared can be called in any manner whatsoever (any number of arguments), it's a bad idea to do that without issuing a diagnostic about an undeclared function being used. If such a diagnostic isn't enabled by default it's a bad idea not to add that. C programmers have to understand the diagnostic power of their toolchain. Recently, GCC 11 found a problem in some code of mine. I had converted malloc/free code for a trivial amount of memory to use alloca. But somehow I left in a free call. That was not diagnosed before, but now it was diagnosed. Another obscure bug that a newer compiler with newer diagnsotics caught for me in the last few years was a piece of code where a comparison like this was being made: d <= UINT_PTR_MAX where d is a double. The idea was to try to check whether d is in the range of a certain integer type before converting it. Trouble is that the above expression moves the goalpost because when UINT_PTR_MAX is 64 bit, then its value is not necessarily representable in the double type. What happens is UINT_PTR_MAX is converted to double, and in that process it goes to a nearby double value which happens to greater than UINT_PTR_MAX! And so then the range check becomes wrong: it includes d values in that extended range, which are beyond the range of that integer type, causing undefined behavior in the conversion.
    • kaba0 5y ago
      C is a statically, but weakly typed language with very few compile time checks and many non-intuitive automatic casts.
  • machiaweliczny 5y ago
    TS has good option of being optional. I programmed C++ (rigid niminal), Ruby (duck), Haskell and TS is best compromise so far as it works like tested documentation which is most practical for many purposes (where program must be iterated). If you know what you want to build beforehand then sound typing might be better.
  • dboreham 5y ago
    The wheel of typing.
• jcrben 5y ago
  What course?
  • jjice 5y ago
    It was at my university unfortunately, but the content is likely covered by any course labeled as "programming language theory" or something similar.