5 ms·

As a language designer, I’m glad to hear my goals might resonate with somebody. :) Dynamic typing is easy to implement, and that’s about as far as its value go

As a language designer, I’m glad to hear my goals might resonate with somebody. :) Dynamic typing is easy to implement, and that’s about as far as its value goes, as far as I’m concerned. If your static type system is getting in your way, you need a better static type system, not a dynamic one. The same goes for dynamic scope—much as I like having it available in Perl and Emacs Lisp, it’s best used sparingly. Memory safety is also kind of a no-brainer. I enjoy working at all levels of abstraction, and having control over memory layout is great, but I don’t miss it when working in a higher-level language. Compilers and runtimes for statically typed languages can usually be trusted on matters of value representation. Efficient storage reclamation is something I’m particularly concerned with. In the absence of mutability and laziness, refcounting is an excellent GC replacement because you can’t get cycles. :) I came to that choice from working with Haskell—it’s wonderful, but it suffers from performance issues due to the GC–laziness combination. Both immensely useful features, to be sure, but they come at a cost. OCaml hits a certain sweet spot: it uses GC, but also eager evaluation by default; has convenient access to mutable values; and the runtime uses unboxed primitives. Windows support is…well, an unfortunate truth. The state of programming on Windows isn’t great outside the Microsoft stack—MinGW and Cygwin notwithstanding, as “using Windows to emulate Unix” isn’t the same as “using Windows”. Language designers have a sad tendency to neglect Windows as a platform but I can’t quite tell why. Can it be just because they work primarily with Linux, Unix, or OS X?

smoyer 13y ago
Amazing ... you just restated the article in half as many words, and avoided sounding like a prima donna. This is a useful skill if you actually want people to listen to you.
- evincarofautumn 13y ago
  HN comments and blog articles are how I practice writing. Haven’t been writing any blog articles lately, so.
  - smoyer 13y ago
    I intended my comment to be a compliment ... in fact, I'd written and discarded what I decided was a "too nasty" comment about the OP's article.
Mikera 13y ago
Refcounting?? I thought that idea died years ago. Refcounting is an extremely poor choice for memory management on modern machines. Even putting aside the issue that it can't handle cycles: constantly writing to memory to modify reference counts can be a huge performance hit (you often have to do it even when you are accessing objects in a read-only fashion). Also it requires extra memory on a per-object basis. Also it doesn't play nicely with concurrent threads. Also it's not cache friendly. I'd expect any halfway-decent modern GC implementation to be significantly more efficient than reference counting. About the only valid justification I can see nowadays for not using a GC is a hard-realtime latency requirement. Yep, GC pauses suck. But for efficient memory management in nontrivial systems, GCs are definitely the state of the art.
- deleted 13y ago
  [deleted]
- evincarofautumn 13y ago
  You’re right in the general case. My language does not have mutation, so refcounting is[1] just an optimisation to avoid copying and allow in-place mutation when the refcount is 1; it only applies to boxed values. I should have said “copy on write”. And I’m well aware of modern GC implementations, but one of my goals is deterministic memory behaviour, a feature lacking in other functional languages. I swear I know what I’m doing. :) [1]: Read: will be; the current implementation is interpreted but I’m working with a friend on an x86_64 VM target.
- haberman 13y ago
  > Refcounting is an extremely poor choice for memory management on modern machines. Tell that to Linus: Data structures that have visibility outside the single-threaded environment they are created and destroyed in should always have reference counts. In the kernel, garbage collection doesn't exist (and outside the kernel garbage collection is slow and inefficient), which means that you absolutely _have_ to reference count all your uses." https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle Just to balance your downsides of refcounting, some downsides of GC: requires halting the program periodically and trashing all the caches, which is inconvenient and sometimes impossible. And performance-wise it's unpredictable and can require lots of tuning, as Java programmers who work on allocation-heavy workloads can attest.

smoyer 13y ago

Amazing ... you just restated the article in half as many words, and avoided sounding like a prima donna. This is a useful skill if you actually want people to listen to you.

evincarofautumn 13y ago
HN comments and blog articles are how I practice writing. Haven’t been writing any blog articles lately, so.
- smoyer 13y ago
  I intended my comment to be a compliment ... in fact, I'd written and discarded what I decided was a "too nasty" comment about the OP's article.

Mikera 13y ago

Refcounting?? I thought that idea died years ago. Refcounting is an extremely poor choice for memory management on modern machines. Even putting aside the issue that it can't handle cycles: constantly writing to memory to modify reference counts can be a huge performance hit (you often have to do it even when you are accessing objects in a read-only fashion). Also it requires extra memory on a per-object basis. Also it doesn't play nicely with concurrent threads. Also it's not cache friendly. I'd expect any halfway-decent modern GC implementation to be significantly more efficient than reference counting. About the only valid justification I can see nowadays for not using a GC is a hard-realtime latency requirement. Yep, GC pauses suck. But for efficient memory management in nontrivial systems, GCs are definitely the state of the art.

deleted 13y ago
[deleted]
evincarofautumn 13y ago
You’re right in the general case. My language does not have mutation, so refcounting is[1] just an optimisation to avoid copying and allow in-place mutation when the refcount is 1; it only applies to boxed values. I should have said “copy on write”. And I’m well aware of modern GC implementations, but one of my goals is deterministic memory behaviour, a feature lacking in other functional languages. I swear I know what I’m doing. :) [1]: Read: will be; the current implementation is interpreted but I’m working with a friend on an x86_64 VM target.
haberman 13y ago
> Refcounting is an extremely poor choice for memory management on modern machines. Tell that to Linus: Data structures that have visibility outside the single-threaded environment they are created and destroyed in should always have reference counts. In the kernel, garbage collection doesn't exist (and outside the kernel garbage collection is slow and inefficient), which means that you absolutely _have_ to reference count all your uses." https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle Just to balance your downsides of refcounting, some downsides of GC: requires halting the program periodically and trashing all the caches, which is inconvenient and sometimes impossible. And performance-wise it's unpredictable and can require lots of tuning, as Java programmers who work on allocation-heavy workloads can attest.