5 ms·

Removing dead code is incredibly valuable. Even in time-consuming environments with highly effectful languages it can mean the difference between pulling in and

Removing dead code is incredibly valuable. Even in time-consuming environments with highly effectful languages it can mean the difference between pulling in and maintaining old/archaic dependencies or not. I wish more of our static analysis tools for non-functional languages had better concepts of purity. There are so many places where it fails in languages without this concept. eg: Java annotations can change the behavior of a method from a simple getter to something else entirely with hooks to be used/referenced at runtime. One place I have found that static analysis fails is with API contexts. Either they get it wrong and offer to remove API elements or they get it less-wrong and just don't touch anything that can be exported. Granted getting it right would require all usages of the API or a blessed list of things we know we want to keep ... in which case we are potentially back at our source code as a source of truth anyway. Another interesting hole is "do we keep code that is only referenced by tests?" In some cases, it makes sense but it's definitely a knob that the user needs to adjust manually so far as I have seen.

Twisol 6y ago
> eg: Java annotations can change the behavior of a method from a simple getter to something else entirely with hooks to be used/referenced at runtime. To be slightly fair to Java, annotations don't themselves do anything to the annotated method. Calling a method directly is the same regardless of whatever annotations are on it -- of course, unless it or one of its upstreams looks at the annotations, but that's isomorphic to just passing the data along. Java annotations induce different behaviors in specific callers that are designed to take advantage of those annotations, which is arguably even worse -- like a meta analogue of the COMEFROM keyword.
- imoverclocked 6y ago
  Totally agree. The annotations basically just mark code. Things like AspectJ can then place side-effects around marked (and unmarked!) code. Also, coming across transient runtime errors because you use multi-catch (a basic Java language feature) and some java library that injects bytecode is pretty lame. All the benefits of a typed+compiled language with all the benefits of monkey patching!
- ajuc 6y ago
  As an aside I don't understand why COMEFROM has that bad reputation. It's just another name for aspects.
  - Twisol 6y ago
    C# delegates are a kind of COMEFROM, from a certain perspective, so it's not a universally bad idea. The problem is just that using it in conjunction with other kinds of control flow -- like the @Annotations + method calls approach we see in Java -- tends to obscure the control flow overall and make it a lot harder to follow the high-level behavior of your system.
bjoli 6y ago
DCE is also extremely valuable when writing lisp macros. Not having to do DCE in the macro is saves a lot of code. There is a talk by Kent Dybvig called "the macro writer's bill of rights" on YouTube that goes into optimizations that help macro writers.
- deleted 6y ago
  [deleted]

Twisol 6y ago

> eg: Java annotations can change the behavior of a method from a simple getter to something else entirely with hooks to be used/referenced at runtime. To be slightly fair to Java, annotations don't themselves do anything to the annotated method. Calling a method directly is the same regardless of whatever annotations are on it -- of course, unless it or one of its upstreams looks at the annotations, but that's isomorphic to just passing the data along. Java annotations induce different behaviors in specific callers that are designed to take advantage of those annotations, which is arguably even worse -- like a meta analogue of the COMEFROM keyword.

imoverclocked 6y ago
Totally agree. The annotations basically just mark code. Things like AspectJ can then place side-effects around marked (and unmarked!) code. Also, coming across transient runtime errors because you use multi-catch (a basic Java language feature) and some java library that injects bytecode is pretty lame. All the benefits of a typed+compiled language with all the benefits of monkey patching!
ajuc 6y ago
As an aside I don't understand why COMEFROM has that bad reputation. It's just another name for aspects.
- Twisol 6y ago
  C# delegates are a kind of COMEFROM, from a certain perspective, so it's not a universally bad idea. The problem is just that using it in conjunction with other kinds of control flow -- like the @Annotations + method calls approach we see in Java -- tends to obscure the control flow overall and make it a lot harder to follow the high-level behavior of your system.

bjoli 6y ago

DCE is also extremely valuable when writing lisp macros. Not having to do DCE in the macro is saves a lot of code. There is a talk by Kent Dybvig called "the macro writer's bill of rights" on YouTube that goes into optimizations that help macro writers.

deleted 6y ago
[deleted]