“Racket knows too little about my program—it can’t figure out what I mean based on the type of thing I’m operating on because it is (mostly) dynamically typed. I still have to clarify myself and write things that feel redundant because the computer isn’t smart enough to figure out the “obvious”. Similarly, Haskell is too limiting—the compiler cannot deduce constraints I can solve in my head in seconds, and its syntax is not extensible like Racket’s is. Every day, I peer into piles upon piles of monadic computation, and really, what have I gained?”
It’s a good article but the author gave up too early. Racket has a Typed Racket variant that could be used to aid understanding. That plus a Design-by-Contract style. On Haskell’s end, the author might like dependently typed languages like IDRIS that would increase constraints that could be solved. There’s also old approach of doing side-by-side projects in a spec language good for one thing and implementation language good for other things. Finally, one can use the power of a LISP like Racket to embed another readable, typed language with benefits of macros. I did that with a custom, BASIC-like 4GL that compiled to C. sklogic on Hacker News has a toolkit for writing compilers, etc with LISP-based DSL’s where he alternates between using DSL’s (including Standard ML) or LISP itself. Julia’s language designers also took the approach by creating a tiny, efficient LISP (femtolisp) then building a human-readable, effective language on top of it. Combines benefits of scripting languages, LISP’s (esp macros & compiler transforms), and native languages.
So, I’m not sure why author stopped there. Rabbit hole leads to plenty more options along author’s range of desired capabilities with tooling that already exists to help create those capabilities.
In the Racket example, the Racket DSL would be a form of Haskell that looks just like normal Haskell. You code it the same way. The difference is you’re actually using Racket and get its benefits during development. The extracted code matches or mostly matches what you put in by hand. So, it will look like hand-written Haskell. I hope that makes more sense than my original explanation.
“I want to improve our tooling, but people around me lag somewhat behind.”
It helps to find intermediate points that work in their comfort zone. An example is adding basic annotations for Design-by-Contract. You show how it prevents breaks during modifications. You might then add a tool that generates tests directly from the specs. So, it saves time in test generation or maintenance. You might later on show that it can support static analysis to verify correctness of a fast path algorithm. So on and so forth.
Parser and protocol generators are another one where benefits are clear. You learn the input language once. Then, tool does cumbersome work for you. Long ago I also had one for GUI’s. A combo of heuristics and an input language auto-generated forms for me that were reasonable. Most business apps were CRUD apps so it worked nicely. Another is automating the database layer with a DSL in a way that works with multiple DB’s or avoids stuff like ORM. An example is object-based DB, AllegroCache, where it looks mostly like a regular class definition. Tooling handles the DB parts in the background with ACID properties.
So, there’s different things you can do if you focus on incremental stuff that reduces their workload or significantly improves quality with minimal effort.
As I usually do, I’ll ask what your opinion is on the Sequent Calculus it uses for advanced typing. I get very little info on it when Shen comes up. I’m curious if it can do what dependently typed languages can do with ease or difficulty. Or what else it’s comparable to that I might understand.
As I understand it, the sequent calculus compiles to horn clause logic, which is very similar to the sort of logic that Prolog is built on.
The author talks about dependent types here. He says that the language has a “Turing complete type system” which is an impressive boast.
The trouble with the language is that despite all these nice properties, it’s difficult to actually do anything with it on account of the lack of libraries and tutorials. It’d be a great language to sequester yourself on a mountain retreat with.
“Racket knows too little about my program—it can’t figure out what I mean based on the type of thing I’m operating on because it is (mostly) dynamically typed. I still have to clarify myself and write things that feel redundant because the computer isn’t smart enough to figure out the “obvious”. Similarly, Haskell is too limiting—the compiler cannot deduce constraints I can solve in my head in seconds, and its syntax is not extensible like Racket’s is. Every day, I peer into piles upon piles of monadic computation, and really, what have I gained?”
It’s a good article but the author gave up too early. Racket has a Typed Racket variant that could be used to aid understanding. That plus a Design-by-Contract style. On Haskell’s end, the author might like dependently typed languages like IDRIS that would increase constraints that could be solved. There’s also old approach of doing side-by-side projects in a spec language good for one thing and implementation language good for other things. Finally, one can use the power of a LISP like Racket to embed another readable, typed language with benefits of macros. I did that with a custom, BASIC-like 4GL that compiled to C. sklogic on Hacker News has a toolkit for writing compilers, etc with LISP-based DSL’s where he alternates between using DSL’s (including Standard ML) or LISP itself. Julia’s language designers also took the approach by creating a tiny, efficient LISP (femtolisp) then building a human-readable, effective language on top of it. Combines benefits of scripting languages, LISP’s (esp macros & compiler transforms), and native languages.
So, I’m not sure why author stopped there. Rabbit hole leads to plenty more options along author’s range of desired capabilities with tooling that already exists to help create those capabilities.
Author obviously cares deeply about fellow humans understanding the code as well. Not sure how the Racket-generated Haskell would fare on that front.
Actually, I am in the exact same spot as her. I want to improve our tooling, but people around me lag somewhat behind.
In any case… Good luck!
In the Racket example, the Racket DSL would be a form of Haskell that looks just like normal Haskell. You code it the same way. The difference is you’re actually using Racket and get its benefits during development. The extracted code matches or mostly matches what you put in by hand. So, it will look like hand-written Haskell. I hope that makes more sense than my original explanation.
“I want to improve our tooling, but people around me lag somewhat behind.”
It helps to find intermediate points that work in their comfort zone. An example is adding basic annotations for Design-by-Contract. You show how it prevents breaks during modifications. You might then add a tool that generates tests directly from the specs. So, it saves time in test generation or maintenance. You might later on show that it can support static analysis to verify correctness of a fast path algorithm. So on and so forth.
Parser and protocol generators are another one where benefits are clear. You learn the input language once. Then, tool does cumbersome work for you. Long ago I also had one for GUI’s. A combo of heuristics and an input language auto-generated forms for me that were reasonable. Most business apps were CRUD apps so it worked nicely. Another is automating the database layer with a DSL in a way that works with multiple DB’s or avoids stuff like ORM. An example is object-based DB, AllegroCache, where it looks mostly like a regular class definition. Tooling handles the DB parts in the background with ACID properties.
So, there’s different things you can do if you focus on incremental stuff that reduces their workload or significantly improves quality with minimal effort.
Typed Racket is a great suggestion, but might I also recommend Shen.
As I usually do, I’ll ask what your opinion is on the Sequent Calculus it uses for advanced typing. I get very little info on it when Shen comes up. I’m curious if it can do what dependently typed languages can do with ease or difficulty. Or what else it’s comparable to that I might understand.
As I understand it, the sequent calculus compiles to horn clause logic, which is very similar to the sort of logic that Prolog is built on.
The author talks about dependent types here. He says that the language has a “Turing complete type system” which is an impressive boast.
The trouble with the language is that despite all these nice properties, it’s difficult to actually do anything with it on account of the lack of libraries and tutorials. It’d be a great language to sequester yourself on a mountain retreat with.