Dave Eckhardt

As for JavaScript, Google Closure Compiler does some dead code elimination (DCE, a.k.a. tree shaking in Lisp lingo) as an optimization but it unfortunately doesn't tell you which parts of the code is dead. It also does not to DCE alone but does some aggressive size optimizations with it so, again unfortunately, it cannot output otherwise-identical code with only DCE applied.

This part is more of a shameless plug, but I believe public/industry/developers should be aware of what tools & techniques academia develops so that the researcher's efforts can be more useful. There are some static analyzers for JavaScript such as JSAI, SAFE, and TAJS (disclaimer: I'm working on a project related to JSAI on the lab which developed it). These static analyzers can discover the dead code if given all the entry points however:

- They don't have facilities to report the dead-code AFAIK (this is a trivial thing to add _in theory_, if there are parts of the program _unvisited_ by any of these, that part of the program is guaranteed to be dead). If somebody wants to add such a facility to any of the tools they are welcome. In case of JSAI, I'm willing to provide them all the information I can.

- They are conservative (e.g. sound) tools and may find too few dead code results.

- They don't play well with `eval` & friends in general although they try their best[0], the web frameworks rely on eval-like highly-dynamic approaches a lot to be generic enough and that hurts precision of such…

It will be hard to come up with an accessible general framework to express general problem situations without resorting to either (a) an explosion of templates for solving the N-most-common kinds of problems (the browsing through which will be worse than learning the math and the programming); (b) a set of elaborate but limiting special-purpose programs (much like iPhone apps that might help, for example, a metal welder to choose stock feed rate, gas mix/flow, and electric current depending on metal type and thickness to be joined; or mortgage calculators).

Worse yet, it doesn't take much for interesting problems to get into the land of over- or under-constraint. In an under-constrained problem there are a multitude of solutions forming their own K-dimensional space, and then one likely should apply some secondary optimization criteria to determine the best solution. In over-constrained problems there is no exact solution, but again one needs to impose some optimization to get something "close enough" to the desired criteria, according to some norm. Explaining the need for optimization, letting the user explore the solution space, and having them express these optimization criteria will be tough.

A Google search for "geometric constraint solver" leads to this paper: http://www.cs.purdue.edu/homes/cmh/distribution/papers/Constraints/CAD95.pdf -- what appears to be a lot of work just in helping people/machines solve geometric problems (though surely more widely…

Very, very excited about Scala 3. Here are some of the things I'm looking forward to using:

* Generally a more clean language for everyday use, codifying existing patterns like newtypes (opaque types), typeclass derivation and extension methods

* Improved type inference & lots of other quality of life improvements

* A macro system based on the idea of multi-stage programming. This has a lot of potential for improving both type-safety and performance. An example: beating existing database systems query optimization with ~500 lines of Scala code [1]

* TASTY, a new intermediate representation (AST) for artifacts. This means that Scala will have a much better version upgrade / binary compatibility story in the future. (e.g. TASTY is used for facilitating 2.13 <-> 3.0 bi-direction upgrade!)

* Significant compile time improvements over Scala2 alraedy[2] (and we're only at M1 release)!

Scala has already been a wonderful language to work with professionally with many great tooling (linting, automatic migration, 2 good OSS IDEs), and I think Scala 3 will certainly push the state-of-the-art forward in many departments in the coming years.

[1]:https://www.cs.purdue.edu/homes/rompf/papers/rompf-icfp15.pdf

[2]: https://twitter.com/not_xuwei_k/status/1323643312230772737

I think the major problem in CAD/CAM software is the creation of technical drawings.

I enjoy every new CAD program (solvespace, implicitCAD, nanoCAD, ...) when they come but each time it lacks this vital function. Even fat dinausors like CATIA, Pro/E, Inventor & co have a very poor ux at that level.

So I will recommend to master the rules of technical drawings and geometric dimensionning and tolerancing before going to deep in 3D. Likewise, BRep, CSG, constraints solvers, code/GUI will be just straightforward "plugins". It's safer and more useable in real life.

By the way, the Purdue University have some good innovative lectures, ie. Erep [1]

Computer Aided Engineering Design by Anupam Saxena & Birendra Sahay is cool and informative.

In general, the Indian Institute of Technology of Kampur [2] has some pretty intense books on the subject.

Finally, Knowledge-based engineering [127] will extend a lot your future awesome opensource haskell CAD package!

[1] https://www.cs.purdue.edu/homes/cmh/distribution/papers/Erep/

[2] http://www.iitk.ac.in/cad/

[127] https://en.wikipedia.org/wiki/Knowledge-based_engineering

Check out the Delta Debugging paper. There has been a ton of follow-on work (1000+ direct citations), and lots of tools exist.

Here's the citation, abstract and link to a PDF copy:

Simplifying and isolating failure-inducing input
Andreas Zeller, Ralf Hildebrandt
IEEE Transactions on Software Engineering 28 (2), 183-200, 2002

Given some test case, a program fails. Which circumstances of the test case are responsible for the particular failure? The delta debugging algorithm generalizes and simplifies the failing test case to a minimal test case that still produces the failure. It also isolates the difference between a passing and a failing test case. In a case study, the Mozilla Web browser crashed after 95 user actions. Our prototype implementation automatically simplified the input to three relevant user actions. Likewise, it simplified 896 lines of HTML to the single line that caused the failure. The case study required 139 automated test runs or 35 minutes on a 500 MHz PC.

http://cs.purdue.edu/homes/xyzhang/fall07/Papers/delta-debugging.pdf

Edit: adjusted tone

> We observe that they essentially solve the same problem, i.e., how to store a collection of sorted integers with as few as possible bits and support query processing as fast as possible. Due to historical reasons, bitmap compression and inverted list compression were developed as two separated lines of research in the database area and information retrieval area.

https://www.cs.purdue.edu/homes/csjgwang/pubs/SIGMOD17-Bitmap.pdf

Presentation slides https://pdfs.semanticscholar.org/32bc/322fce0cf6c99b0dd31f1aa2e271525357f8.pdf

Mentioned in https://github.com/junchangwang/reading-list/blob/main/Database/Bitmap.md

see also

https://roaringbitmap.org/publications/

If you like this, you might like the work of https://en.wikipedia.org/wiki/Gonzalo_Navarro

The lead author has a great body of research https://www.cs.purdue.edu/homes/csjgwang/pubs/