Live data from Hacker News

Borrow-checking without type-checking

scattered-thoughts.net

21–30 of 35 posts

Re: Borrow-checking without type-checking

#21
post #4

In my programming language I have some sort of "borrowing" too (although it's named differently). But my language has no dynamic typing, only static typing is used and thus all checks are compile-time and have no runtime cost. Why bothering with dynamic typing and paying runtime costs for it?

Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

There is no consistent definition of the term "weak typing". Do you mean implicit coercion?

> Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

Ironically, I would counter that, in my experience, most people who have a problem with static typing actually have a problem with verbose type systems, like Java's or C++'s — or Rust's. (Rust is at least gaining something for its verbosity.)

Type inference is a neat way to bridge the gap. OCaml, Haskell, and Swift (to name a few) all feature distinct type inferencing that give you the benefits of static types without as much syntactic overhead.

Re: Borrow-checking without type-checking

#22
post #4

Earlier quoted context omitted.

Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

There is no consistent definition of the term "weak typing". Do you mean implicit coercion? > Most people who think they have a problem with dynamic typing actually have a problem with weak typing. Ironically, I would counter that, in my experience, most people who have a problem with static typing actually have a problem with verbose type systems, like Java's or C++'s — or Rust's. (Rust is at least gaining something…

I deeply deeply want to love OCaml but its inherent lack of dynamic dispatch for int / float / complex is brutal

Re: Borrow-checking without type-checking

#23
post #4

Earlier quoted context omitted.

Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

There is no consistent definition of the term "weak typing". Do you mean implicit coercion? > Most people who think they have a problem with dynamic typing actually have a problem with weak typing. Ironically, I would counter that, in my experience, most people who have a problem with static typing actually have a problem with verbose type systems, like Java's or C++'s — or Rust's. (Rust is at least gaining something…

Nim type inference was a joy to use although I haven't touched the language in several years due to the language community seeming to collapse a bit.

Re: Borrow-checking without type-checking

#24
post #4

In my programming language I have some sort of "borrowing" too (although it's named differently). But my language has no dynamic typing, only static typing is used and thus all checks are compile-time and have no runtime cost. Why bothering with dynamic typing and paying runtime costs for it?

Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

Sorta? Python has fairly strong types but it's no fun debugging a `None has no attribute foo` error deep inside some library function with a call site 1000 LoC away from the actual place where the erroneous None originally arose, due to a typo.

It's not just Python too, I've hit the same issue in Common Lisp.

Yes one can run contracts and unit tests and static analysis, but what's a type checker anyway other than a very strict static analysis tool?

Re: Borrow-checking without type-checking

#25
post #4

In my programming language I have some sort of "borrowing" too (although it's named differently). But my language has no dynamic typing, only static typing is used and thus all checks are compile-time and have no runtime cost. Why bothering with dynamic typing and paying runtime costs for it?

Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

Dynamic typing doesn't scale in large teams, it is however great in small projects, or if optional typing is supported, which took a long time to learn from languages like structured BASIC dialects.

It is no accident that all mainstream dynamic languages now have optional typing support, either in the language directly or via linters.

Re: Borrow-checking without type-checking

#26
post #4

In my programming language I have some sort of "borrowing" too (although it's named differently). But my language has no dynamic typing, only static typing is used and thus all checks are compile-time and have no runtime cost. Why bothering with dynamic typing and paying runtime costs for it?

Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

> Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

No, the real actual problem is with invisibility aka: the absence of readability:

In a "dynamic typing" program the interpreter knows what `a` is but YOU not.

In very strong sense. You can imagine that `a` is a `int` because, well, you write the program, right? But in fact, is only probabilistic assumption.

Some day, `a` will be a program that delete the files of your computer.

Re: Borrow-checking without type-checking

#27
post #25
post #4

Earlier quoted context omitted.

Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.

Dynamic typing doesn't scale in large teams, it is however great in small projects, or if optional typing is supported, which took a long time to learn from languages like structured BASIC dialects. It is no accident that all mainstream dynamic languages now have optional typing support, either in the language directly or via linters.

Oh yeah, I'm massively in favour of gradual typing. Python's choice to not actually enforce type hints is perhaps the most moronic language design I've ever seen.

Re: Borrow-checking without type-checking

#28

Can someone help confirm whether I understand correctly the semantics difference between the final-line eval of x^ vs. x* ? It seems like either one evaluates the contents of the `box`, and would only make a difference if you tried to use `x` afterwards? Essentially if you final-line eval `x^` and then decide you want to continue that snippet, you can't use `x` anymore because it's been moved. Awkwardly, it also hasn…

> It seems like either one evaluates the contents of the `box`, and would only make a difference if you tried to use `x` afterwards?

More or less. x^ moves the whole box whereas x* copies the contents of the box.

> Awkwardly, it also hasn't been assigned so I'm not sure the box is accessible anymore?

Yes, if you move something and don't assign it then it gets dropped, same as rust.

Re: Borrow-checking without type-checking

#29
post #28

Can someone help confirm whether I understand correctly the semantics difference between the final-line eval of x^ vs. x* ? It seems like either one evaluates the contents of the `box`, and would only make a difference if you tried to use `x` afterwards? Essentially if you final-line eval `x^` and then decide you want to continue that snippet, you can't use `x` anymore because it's been moved. Awkwardly, it also hasn…

> It seems like either one evaluates the contents of the `box`, and would only make a difference if you tried to use `x` afterwards? More or less. x^ moves the whole box whereas x* copies the contents of the box. > Awkwardly, it also hasn't been assigned so I'm not sure the box is accessible anymore? Yes, if you move something and don't assign it then it gets dropped, same as rust.

Great, thanks for the clarification!
Post reply on HN