17 ms·

> I can no longer concieve of writing software without using test driven development. I can't imagine not having a comprehensive suite of unit tests to back u

• capableweb 5y ago
  > if you haven't coded in a language like OCaml, Haskell, ML etc Same argument could be made the other way, if you haven't used Smalltalk, Clojure (and other languages that are strongly dynamic), you shouldn't discount them.
  • DaiPlusPlus 5y ago
    > strongly dynamic Que?
    • enricozb 5y ago
      class A(random.choice([B, C]): ...
      • rphln 5y ago
        I don't know whether to feel disgusted or fascinated by this. I find the concept of prototype-based inheritance quite elegant, but this is a bit too much insane.
        • professoretc 5y ago
          There was an experimental language called Cecil that had "conditional inheritance". You could say things like class Rectangle: var w,h class Square(Rectangle if w == h): ... You could then overload functions/methods on both `Square` and `Rectangle` and it would call the correct overload depending on the runtime values of `w` and `h`.
    • dgb23 5y ago
      They are dynamic to a degree that facilitates interactivity and expression on a different level than one might be used to. Late binding, REPL, expression based, building up code while it is running without losing state etc.
      • DaiPlusPlus 5y ago
        But none of those things you mentioned are dependent on a dynamic type system: on the contrary, plenty of statically-typed languages offer late-binding, expressions (certainly enough to implement a REPL) - I know C# certainly has all of those things. The last thing: being able to edit program code, add new types/members/functionality and so-on while it's running... that's not really a language limitation nor typing-system limitation either: that's just good tooling that is able to hot-swap executable code after the process has already started. Visual Studio has had "Edit & Continue" in debugging sessions for almost 3 decades now, and the runtime build system used by ASP.NET means that source code and raw aspx/cshtml views can still be FTP'd up to production and just work, because .NET supports runtime compilation. ------------ For ordinary business software, where the software's focus is on data-modelling and data-transforming-processes, so all these programs basically just pass giant aggregates of business data around, so strong-typing is essential to ensure we don't lose any properties/fields/values as these aggregate objects travel through the software-proper. In this situation there is absolutely no "expressiveness" that's could be gained by simply giving up on type-correctness and instead rely on unit tests (and hope you have 100% test coverage).
        • capableweb 5y ago
          > For ordinary business software, where the software's focus is on data-modelling and data-transforming-processes, so all these programs basically just pass giant aggregates of business data around, so strong-typing is essential to ensure we don't lose any properties/fields/values as these aggregate objects travel through the software-proper. There is also ways of dealing with this in dynamic languages. For example, Clojure has clojure.spec that achieves the same results, but without relying on strong typing. In the end, it's all tradeoffs. There is no "one solution" that will be perfect for everything.
    • hultner 5y ago
      A strongly typed dynamic language will raise an type error if you for instance try to add two incompatible types, for instance in python Python 3.9.0 (default, Oct 10 2020, 11:40:52) [Clang 11.0.3 (clang-1103.0.32.62)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 1+"1" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' While a weakly typed dynamic language like JS will allow for it Welcome to Node.js v16.0.0. Type ".help" for more information. > 1 + "1" '11'
      • dragonwriter 5y ago
        If the language allows it the types are (ipso facto) not incompatible; “weak typing” is more a subjective statement about how well a language lines up with the speakers mental model of what types should be compatible than an objective one about falsifiable properties of the type system.
        • gpderetta 5y ago
          Agree. Weakly typed is so loosely defined and subjective to be a completely useless adjective. It basically a synonym for 'language I dislike'.
          • goatlover 5y ago
            How about some languages allow implicit type conversions, and others do not.
            • iso8859-1 5y ago
              Is Scala weakly typed then because it has implicits?
              • goatlover 5y ago
                I don't know, but JS and PHP implicit conversions are widely acknowledged to cause plenty of issues, which Python and Ruby do not have since you have much fewer cases of implicit conversion.
  • skohan 5y ago
    Once upon a time I was writing a lot of Objective-C, and back then I found it really cool and fun to embrace the potential of dynamic dispatch. But when I did get bit, the thing that was painful about it is that runtime failures often occurred way far away from the source of the issue, so debugging was often extremely painful. I'm, not sure if Smalltalk and Clojure do this better, but since I've gotten into static languages, I basically haven't looked back, and I haven't missed the dynamism much at all.
    • capableweb 5y ago
      You're making exactly the same point as seanwilson did above. "I have used this dynamic language and it was worse than this strong static type language" while not even tried something like Smalltalk or Clojure. Yes, languages that are truly dynamic (ships with a REPL, has a instant change->run this snippet workflow, can redefine anything in the runtime AT runtime) does work a lot better than Python which is basically comparing the type systems of Java and Haskell. Give it a try. Worst that can happen is that you now have tried and learned something different, I'm sure it'll give you some knowledge that'll be helpful in any programming language :)
      • skohan 5y ago
        I thought Objective-C was basically smalltalk, but maybe I'm mistaken
        • tester89 5y ago
          Objective-C adopted some syntactic "quirks" from smalltalk, but they are not similar at a semantic level.
          • skohan 5y ago
            What are the key differences? My understanding was that both languages are heavily built around message passing between objects and dynamic dispatch.
  • reader_mode 5y ago
    I've coded in Clojure enough to know that there are cases where it completely sucks (mostly when you have to do imperative low level code). I used to have a link to a standard library implementation of channels that was downright hideous to read as an example of this (and that code transformed to Java is actually easier to follow). Clojure has some cases where it's insane how elegant you can make the solution, but frankly static languages with good type systems and tooling come close enough but don't have the scaling downsides.
    • capableweb 5y ago
      > I've coded in Clojure enough to know that there are cases where it completely sucks Yeah, agree. But this is hardly surprising. Learn enough about ANY language on this planet and you'll come to the same conclusion. The beauty of Clojure is that it mostly provides you with tooling and other facilities that leads to elegant and more importantly simple code.
    • bjourne 5y ago
      You can find hideous Haskell code too. Especially in code for which lazy evaluation doesn't work and you need to coax the runtime into computing stuff in the right order.
      • acomar 5y ago
        a rebuild of Haskell that got rid of the dynamic exception system and put laziness/strictness in the type system as an effect is my dream.
• xupybd 5y ago
  And in languages like F# ( I assume the same for other ML like languages) the type system get out of your way. Java can put you off with all the boiler plate. That's not a requirement of static typing.
  • DaiPlusPlus 5y ago
    F# still has rather crippling limitations imposed on it by its inherited .NET CLR type system (for example F# union types must have their own hierarchy: you can't have an F# union with a POCO from another assembly). F# skirts-around some of the limitations with just-in-time design-time type generation ( https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/type-providers/ https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ... ) though Microsoft pitches it as a "better T4" for F# specifically, I think it's far more powerful. The way things are looking, C# is set up get some form of higher-kinded-types in the next 3-5 years (hurrah!) - but from what Mads and the design-team have said it seems like they'll be implemented without significant changes to the CLR's type-system - so be prepared for everything to be implemented as glorified structs (and don't expect struct inheritance either...) with excessive amounts of implicit-conversion.
    • xupybd 5y ago
      Yeah it's not perfect. I might need to look into another functional language. I find it a good gateway. I can use familiar tooling and lean on C# libraries.
      • DaiPlusPlus 5y ago
        Haskell recently got Linear Types baked in officially within the past year, so that's definitely worth taking a look-at.
        • Zababa 5y ago
          What are the use cases for linear types?
    • deleted 5y ago
• noduerme 5y ago
  I miss AS3 compile-time type checking. That was a variation of ECMA4. The closest we have now in the browser is Typescript. And even though it's admittedly pretty elegant with union types and utility types and mixins, some of what it produces is exactly the "noisy defensive code" you're talking about, for the simple reason that it's an elegant language that has to compile down to a worthless untyped jargon like javascript. It's a miracle that the web runs at all on JS.
  • DaiPlusPlus 5y ago
    > some of what it produces is exactly the "noisy defensive code" you're talking about TypeScript, by design, does not produce nor introduce any "noisy defensive code": the point of TypeScript was that type-safety in JavaScript can be achieved without any runtime cost. The only significant code-gen that TypeScript does do by itself is stuff relating to ECMAScript modules (e.g. wrapping and repackaging your TypeScript module for other module systems). ...with the exception of when you take a modern TypeScript compiler and specifically instruct it to target ES3 (lol) or perhaps some older variants of ES5 - at which point the code `tsc` generates is still so minimal you'll still need to bring-your-own polyfill/monkeypatch libraries. This is stuff like reimplementing the spread-operator or `for(of)`, and so on.
    • Lapsa 5y ago
      With all due respect, in my book - TypeScript is mostly useless, vendor lock-in driven bunch of crap. INTELLISENSE111!!!11ELEVEN
      • noduerme 5y ago
        Wha. I still write everything in Eclipse. Neon. And tsc somewhere under v3, compiling back to es5 in some cases to support old safari. Works great for me... lovely language, and zero lock-in.
  • cerved 5y ago
    huh? typescript doesn't compile into type checks at runtime the web runs on JavaScript because it's extremely forgiving and therefore stable. there can be lots of errors and things keep chugging along.
• ideamotor 5y ago
  I would like to use static types, since dynamic types defeat the point by requiring so many checks. I’m still typing a lot. But in my field, I just don’t think it makes sense (data analysis), and frankly it would create a lot of work that would not make me more employable. Maybe some day. Haskell does interest me, but I work in teams that won’t know it.
  • kpmah 5y ago
    I'm a type enthusiast, but dynamic languages make a lot of sense for small programs that either give you an immediate answer or fail to run (i.e. not long running, few branches). In those cases, the difference between a compile-time check and a run-time check is much smaller.
    • pydry 5y ago
      If you have a decent test suite the difference also narrows considerably.
  • chriswarbo 5y ago
    I would say data analysis is actually very well suited to static types. In particular, static types allow us to be much more specific than e.g. string/int/float (AKA "stringly typed programming"). We can use more specific types like 'count', 'total', 'average', 'dollars', 'distance', 'index', etc. all of which are numeric, but we want to avoid mixing up (e.g. counts can be added, but a count should not be added to a distance). I also find 'phantom types' incredibly useful. For example, we might have a database or key/value store, where the keys are represented as strings and the values can be strings, integers, floats, booleans, etc. We can 'label' each key with a "phantom type" corresponding to the values. This way, the compiler knows exactly what types are expected, we only have to handle the expected type, we don't need any boilerplate to wrap/unwrap the database results, etc.: -- Haskell syntax data DBKey t = DBKey String dbLookup :: DBKey t -> Maybe t dbLookup (DBKey key) = ... name = DBKey @String "name" age = DBKey @Int "age" // Scala syntax final case class DBKey[T](override val toString: String) def dbLookup[T](key: DBKey[T]): Try[T] = ... val name = DBKey[String]("name") val age = DBKey[Int ]("age" ) These are called "phantom types" since they don't actually affect anything about how the code runs; in particular, the definition of 'DBKey' requires a type ('t' or 'T') but doesn't actually use it for anything (it just stores a String). We could get rid of these 'labels' and the code would run identically; or we could have the compiler infer all these labels (defaulting to some uninformative type like 'unit' if it's ambiguous). However, the fact that we've explicitly labelled 'name' with String, and 'age' with Int, constrains the rest of our code to treat them as such, otherwise we'll get a compiler error. For example, if we try to look up a name then our result handler must accept a String, and nothing else; if we provide a default age it must be an Int; etc. Of course, we can combine such 'labels' with more meaningful types; so that 'name' looks up a 'Username'; 'age' looks up an 'Age', or a 'Nat', or a 'Duration'; or whatever's convenient. It can also be combined with other type system features like implicits/ad-hoc-/subtype-polymorphism, e.g. to decode JSON as its read from the DB, etc. I've used the example above in real Scala applications when accessing a key/value store. I've also used phantom types (again in Scala) to help me manipulate Array[Byte] values: in that case the bytes could either be 'Plaintext' or 'Encrypted', they could represent either a 'Payload' or a 'Key', and each 'Key' could be intended for either 'Encryption' or 'Signing'. Under the hood these were all just arrays of bytes, and the runtime would treat them as such (using Scala's 'AnyVal' to avoid actually wrapping values up), but these stronger types made things much clearer and safer. For example, we can decrypt and verify a message which carries its own 'data keys' (encrypted with a 'master key'): def decrypt[T]( key : Bytes[Plaintext, Key[Encryption]], data: Bytes[Encrypted, T], ): Try[Bytes[Plaintext, T]] = ... def validated[T]( key : Bytes[Plaintext, Key[Signing]], data: Bytes[Plaintext, T], ): Try[Bytes[Plaintext, T]] = ... def decryptMessage[T]( master : Bytes[Plaintext, Key[Encryption]], dataEnc: Bytes[Encrypted, Key[Encryption]], dataSig: Bytes[Encrypted, Key[Signing ]], message: Bytes[Encrypted, T ], ): Try[Bytes[Plaintext, T]] = for { encKey <- decrypt(master, dataEnc) sigKey <- decrypt(master, dataSig) raw <- decrypt(encKey, message) valid <- validated(sigKey, raw) } yield valid The compiler makes sure we never try to use an encrypted key, we never try to decrypt plaintext, we can't decrypt with a signing key or a payload, we can't validate signatures with an encryption key or a payload, our result type must match the message type, etc. After checking, these types are "erased" to give an implementation of type '(Array[Byte], Array[Byte], Array[Byte], Array[Byte]) => Array[Byte]', which we could have written directly, but I certainly wouldn't trust myself to do so!
• skohan 5y ago
  I almost see static typing as an alternative to exhaustive testing. If you're working on a large project written in JS, you need a strong test suite to have any confidence you code will be robust at runtime. As you say, with ADT's and null safety, you can be a lot more judicious about testing to get to the same level of confidence. When working with Rust or Swift, I'm honestly usually getting away with some integration tests, and whichever unit tests came about organically when a particular section was particularly well suited to TDD. But "code coverage" is a much less pressing concern.
  • zarzavat 5y ago
    If you are writing a new large project in JS without TypeScript, you are doing it wrong period. Bare JS is a cute language for personal websites but it's not feasible for anything more than a few thousand SLOC.
    • dimitrios1 5y ago
      Tell that to the mountain of "few thousand line SLOC" javascript projects that existed and continue to exist before Anders Hejlsberg embarked on his mission to C#-ify javascript. I am not opposed to adding strong type checking to JavaScript, but Typescript ain't it.
      • morgancmartin 5y ago
        I agree that TypeScript leaves something to be desired, but it is far and away a better alternative to pure JS. TS may not be total, but it comes close enough to get the job done for the dynamic environment it's meant to target assuming operators competent enough to lean on what it offers. I should also note, I've attempted OOP in TS and it wasn't pretty. It is much more suited to a functional style IME, although I will concede I have seen some open source projects that use it in a Java-esque OOP style presumably to good effect. Personally it wasn't my cup of tea.
      • wing-_-nuts 5y ago
        >Typescript ain't it. Expand please?
• mpweiher 5y ago
  > you have to pollute your projects with noisy defensive code that double checks the type of everything coupled with extra manually written tests, with no guarantee you didn't miss something. A common misconception. In tests, you test that values are correct, the types take care of themselves. Types being correct does not imply values being correct, so you will have to write those tests anyhow, although you maybe be fooled by the safyness of static typing[1] that you don't have to. Values being correct does imply that the types are correct, so if your tests pass, then your types are also obviously correct. (If a==3 then I don't have to check if a is of type pink elephant, it obviously isn't). So that's the in-principle argument. And it turns out that this is completely supported in practice as well: neither the defensive code nor the extra type-based tests that you propose must be the result actually occur in dynamic code-bases with any frequency. That said, static types certainly have their uses, particularly in being machine-checked documentation and also for producing faster code without going through crazy amounts of extra effort. [1] https://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html https://blog.metaobject.com/2014/06/the-safyness-of-static-t...
  • gpderetta 5y ago
    Unless you can exhaustively check your function for its whole domain, you really can't . Your function could indeed return pink elephants when passed unicorns.
    • dragonwriter 5y ago
      > Unless you can exhaustively check your function for its whole domain, you really can't. If I generate values within a function that are arguments to a constructor call, and the make the constructor call and return the result with no further manipulation, I can—without exhaustive, or even any—testing be quite confident that the function will return the type for which the constructor so called is the constructor any time it returns, and fail otherwise.
      • seanwilson 5y ago
        > and return the result with no further manipulation, I can—without exhaustive, or even any—testing be quite confident But when you start having loops, conditions, arrays, nullable references etc. you can't be so confident any more unlike with proper type checking where you can be fully confident.
• _3u10 5y ago
  It really depends on the team size and a number of other factors. Dynamic languages can be very productive for small teams. I definitely liked the productivity of F#, but the ecosystem was lacking. Often in dynamic languages the ecosystem more than makes up for the lack of compile time checks.
• roenxi 5y ago
  > ... Java, C and C++ have much weaker checks of correctness... It is confusing that people talk about C in terms of being a typed language. The types are an annotation so the compiler knows how much memory to allocate / read. All the side benefits of having to spell that out are incidental. That sort of typing is a distraction. A programmer does not care that they are passing 4 bytes as the first argument. That isn't really trying to squeeze anything useful out of a type system. They care that they are passing something recognised as an ID, not that it has 4 bytes. Using C/C++ as an example of a typed language doesn't say much. The guarantees are more a culture of how to use the language than in the language itself.
  • kaba0 5y ago
    With the same argument, why put C++ into the same bracket? It has much much more type safety than C.
  • edflsafoiewq 5y ago
    struct ID { uint32_t val; }; void check_id(struct ID id);
• kamaal 5y ago
  >>why would I give up getting the computer to automatically check for me at compile time that I'm passing the right number of parameters to a function I never understood this, how is it possible that a developer calling a function doesn't test if they are calling it right. Once they test it, how does the additional compiler test matter? Unless of course your calling function is mutating the value of a variable across so many types that it's impossible to realistically test it. It would then make sense to use a type to prevent the variable from being something it shouldn't. But most people, don't have that situation most of the time. Even in a big application. May be that explains why something like Python has such wide adoption.
  • majjgepolja 5y ago
    The main advantage of typing is, for me, IDE showing errors as you type and better autocomplete, and they serve as documentation also (Of course you should read docs but types are helpful as quick reminder.) Maybe I am just more absent minded than most dynamic programmers, but live IDE diagnostics and autocomplete are very important for me.
    • kamaal 5y ago
      Don't we have support for most of this in language plugins for Python in vscode et al, already?
      • majjgepolja 5y ago
        It's not as accurate or satisfactory in my experience. For example I get errors after running in python, which could be detected in statically typed languages while typing in IDE. Autocomplete is also less than optimal. As for autocomplete intellij IDEs > LSPs for typed languages > Untyped languages IME.
  • kaba0 5y ago
    How many ways can you call a single function? Like, it may be called from a loop, with a quickly changing variable that may change type here or there (especially with weak typing), and you really can’t just say that “I tested it with this one data and it worked”.
• belorn 5y ago
  I do not want static types or unit test. I want integration tests, system test and regression tests, neither which are commonly found by doing trivial checks of correctness. The decision if an integer is stored as a 4 byte or 8 byte, big-endian or little-endian, should be up to the computer to decide. A test to verify that the right integer is sent to the function is something I shouldn't and do not want to be spending time on. The language should be competent enough to figure it out, and if it need to optimize, it should do so dynamically when such optimization is possible. What I found problematic is that system and integration tests is generally relegated to be done outside of the programming process. It is instead the administrators job to write an extensive test system to verify that the program actually do the job that it was written for. You start to wish for a very different set of tool design when the programmer and administrator is the same person.
  • adwn 5y ago
    > The decision if an integer is stored as a 4 byte or 8 byte, big-endian or little-endian, should be up to the computer to decide. What about the decision whether a function argument is an integer or a string? A floating-point value or an optional floating-point value? How could the compiler ever decide that? The size of an integer is only a very, very small part of a modern static type system.
    • belorn 5y ago
      From a system and integration tests perspective, do you care if a function argument is an integer or a string? Is the question relevant to the customer requirements? If a number is an int, float, large or what have you, the question I would ask is how many decimal points should be printed or if you divide 2 with 2, do you get 1 or 0.99999. A good language/compile should have sane defaults that works almost every time, while giving me options to override it if in testing it get an unexpected result where a human would disagree with the computer. The source of tests should be the customer requirements, and types is just an set of automatic tests being applied on the code which has no direct connection to the customer requirements.
      • 5y ago
• qwerty456127 5y ago
  > I can no longer concieve of writing software without using test driven development. I can't imagine not having a comprehensive suite of unit tests to back up my development. I don't understand this. This makes a lot of sense when you make complex enterprise products depending on unstable 3rd-party libraries but for personal project this just inflates the time you need to get the thing done. I just code exactly what I need and check if it works and can't imagine dedicating time to writing additional layer of code to automate this checking. Even when I code pure functions which are a lot easier to test.
  • Zababa 5y ago
    You can see Robert Martin's view on this, even for small and personal projects, here: https://blog.cleancoder.com/uncle-bob/2020/05/27/ReplDrivenDesign.html https://blog.cleancoder.com/uncle-bob/2020/05/27/ReplDrivenD...
    • nodejs_rulez_1 5y ago
      Beware: he makes money or used to make money on TDD training.
    • pydry 5y ago
      I always found him to be a little too zealous about TDD. The circumstances in which it works well are far more limited than he argues.
  • Sharlin 5y ago
    Lately I've been writing some 3D graphics code in Rust for fun. Almost twenty years ago, in highschool, I used to write similar code in C++, without relying on any sort of automated testing – and damn, with the amount of math involved, it's so nice to just write and run some rudimentary sanity-checking tests as you code! I used to rely on constantly building and running some interactive test app and from its behavior try to figure out whether your matrix calculations have a sign error somewhere or not. A solid type system helps a lot in making refactoring a less fearsome endeavour, but a reasonable test coverage on top of static checking makes it even more so. Also, automatic perf tests that keep track of regressions and improvements are just awesome.
• edem 5y ago
  And you also have the problem of writing that type checker in a dynamic language, so you also have no way to check whether the checker itself works according to your specification.
• matheusmoreira 5y ago
  I wonder why gradual typing isn't more common. Shouldn't we be able to have the best of both worlds?
  • eru 5y ago
    Well, in some sense many languages already have gradual typing, it's just not very ergonomic. To give an example from Haskell: You can stick everything into IO, or you can be more careful with your effects. Or to give a more main stream example: Even in a language like Go, you can do lots of runtime casting (which is essentially dynamic typing), or you can try to cajole the type system into recognizing what your are doing statically. You can do the latter effort incrementally.
  • lamontcg 5y ago
    Yeah JSON parsing in statically typed languages is usually at least mildly awful.
• brooklinmyers 5y ago
  I joined a team recently without a solid test suite or testing practices. Really excited to (gently) spread the gospel of TDD (joking). I have the same thought process though, without tests to back me up I feel exposed. Less opinionated/experienced with strong type systems though, I do appreciate the flexibility of being able to hack things together to see if they work - then improving upon the solution. strong types seem to make that harder.
  • justsomeuser 5y ago
    I think strong types actually make this easier. I often build systems, then break them up to take the working parts out, then put a subset back together. The type system is like magnetic Lego that lets you snap pieces together. With a dynamic system it is really difficult to break things apart and then put them back together (without ever running the code, and with 100% accuracy and immediate feedback).
• cageface 5y ago
  Typescript's structural typing plus the "any" escape hatch feels like a pretty good sweet spot to me. 99% of my Typescript code is very strict and I rarely make use of any but it's sometimes nice to have. Writing correct, maintainable software is hard. You need both tests and typechecking.
• zzzeek 5y ago
  > if you haven't coded in a language like OCaml, Haskell, ML etc. you really don't know enough about what strong static types offer to discount them. Java, C and C++ have much weaker checks of correctness and lack type inference + pattern matching that make strong types pleasant to work with. Those are all functional languages, so this argument seems to be the "functional is better than OO" argument, typing is not the primary factor (but of course to the degree that FP allows static typing to be more intuitive, that's a plus). What examples of static typing with OO or procedural languages that are only a "pleasure to work with" can we look at ?
  • klysm 5y ago
    I think functional languages historically have much better type systems but recently, more procedural languages have taken a lot of those innovations and integrated them (e.g. typescript, rust)
    • kragen 5y ago
      The simply-typed lambda-calculus [01940] predated Abadi and Cardelli's object-calculus or sigma-calculus [01996] by 56 years, and both of those have trouble with side effects; the kind of non-sharing thread-safety guarantees Rust's type system can provide for mutable data structures stem from Jean-Yves Girard's "linear logic" [01987] and Wadler's "linear types" [01990], although Reynolds published a POPL paper in 01978 that we can recognize in retrospect as having invented a Rust-like affine typing system. I've never been able to make heads or tails of Girard's paper but http://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-linear-bestiary.pdf http://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-l... is an introductory divulgation of some of the pre-Rust history of this stuff. It makes me think I should read Wadler's 01990 paper. So I think functional languages kind of had a head start, but also in a sense they have an easier problem to solve. ML's type system doesn't even have subtyping, much less mutation and resource leak safety.
      • tome 5y ago
        Thanks, that presentation is absolutely fascinating!
• brightball 5y ago
  > To make up for it in a dynamic language, you end up having to reimplement what a type checker would do for you with no guarantee you didn't miss something or make a mistake, with the added cost of e.g. polluting your projects with noisy defensive code that double checks the types of parameters, adding extra tests, and bolting on linting, analysis and IDE tools to help. This is entirely dependent on the type of application that you're dealing with. A web application backed by a database, especially CRUD style, acts as little more than a pass through layer. You're getting everything as a string from the browser, storing it in the database with a SQL string, usually transformed by an ORM layer. In that style of application, the types are maintained in the database itself. Having a language with strong static typing in that middle layer between the browser and the database only serves to add a huge amount of headaches and extra friction, especially when you're not even using each variable that comes through on its way to the database. The only thing you're doing in that situation is adding an extra set of type checks that you have to keep in sync between the database and the application layer for virtually no benefit.
  • duped 5y ago
    Types have never given me a headache. They've only prevented me from writing bugs and made classes of tests redundant. In your example, the database and the application layer must be kept in sync regardless of whether you use static typing or not. The benefit of static typing is that it can be enforced before you push to production or write a test for congruency.
    • brightball 5y ago
      > kept in sync regardless of whether you use static typing or not This is handled automatically by a large number of ORM tools in dynamic languages (Ruby, PHP, etc). It's a non-issue. I've spent significantly more time in my career debugging issues in statically typed languages used as an app server in front of a database than I have in dynamically typed languages. You're doing some processing work in the language? Calculations, ML, etc? Static typing is the obvious way to go. If you're just sticking things in a database you're going to end up wasting a lot of people's time (and subsequently, the money that goes to pay them). In 20 years, I've never seen it be a good choice but I've seen a lot of people married to the delusion that it is while other people are getting real work done.
• tech_tuna 5y ago
  Would you say that Rust has strong static types?
• dragonwriter 5y ago
  > I’m with the other posters too about the article content, if you haven’t coded in a language like OCaml, Haskell, ML etc. you really don’t know enough about what strong static types offer to discount them. And if you have, you probably know that its awesome but for most purposes doesn’t compensate for the weak ecosystems of the languages that have it, compared either to poorer (higher cost to satisfy for lower benefits) statically typed languages or dynamically typed languages with or without available optional static type checking.
• omegalulw 5y ago
  Also add Agda to your list. It's a good entry point to functional programming!
  • mabelgoodrich 5y ago
    This is really wonderful information and I would love to read more informative posts like this. Being a digital marketing expert at this https://flirtymania.com/de/p https://flirtymania.com/de/p site and help people with cam chat room opportunity, I need to know some basic graphic designing tasks as well as programming language part! Thanks for sharing this post with us.