DSLs typically involves constructing macros that are domain specific (to cobble together a domain specific programming language on top of the host). Most of the linked examples are not macro based and are the exact opposite. They specifying domain specific data layouts built directly using the Clojure-native immutable datatypes. They don't create Domain specific datatypes or function-generating wrappers. It's just rarely necessary
A good example is making GUIs in Clojure. At first there was a cool macro based system called `fn-fx` that maked a JavaFX GUI. Then vlaaad wrote `cljfx` which just used plain Clojure maps and removed the macros entirely. This increased the boilerplate a tiny amount but made the system much more flexible and extensible
> DSLs typically involves constructing macros that are domain specific
a DSL is a constrained language for expressing domain concepts.
in traditional Lisps they are often syntax-oriented, because code is lists and macros are a natural tool.
in Clojure, pervasive use of keywords, vectors and maps allows you to shift DSL design towards data interpretation rather than syntax transformation.
so in Clojure doesn't discourage DSLs - clojure practicioners simply prefer data-oriented DSLs to macro-oriented ones, mostly because they are easier to reason about and process with existing tools, while macros are used more selectively.
The original comment you took issue with "The point being made is that the Clojure style discourages building DSLs and the like and prefers to remain close to Clojure types and constructs". You seemingly read half the sentence and in the most unfavorable way possible. (in context it's clearly not talking about "data-oriented DSLs)
> DSL is a constrained language for expressing domain concepts
What you're calling "data-oriented DSLs" is not constrained.
I guess this is all semantic, but in my book just specifying a data-structure doesn't make a language. You're not extending the host language in any way
> What you're calling "data-oriented DSLs" is not constrained
constraints come from the interpreter, not from the syntax
> in my book just specifying a data-structure doesn't make a language
correct, it does not
what makes it a language is defining constraints on that structure and rules for how it's interpreted
that works both for clojure (where the data structure can involve lists, vectors, maps and primitives) and traditional lisps (where data structure is lists, or to be precise cons cells and primitives)
in both cases macros can be used and are used (but don't have to be used) to prevent immediate evaluation of those data structures according to host language rules and instead change how they are evaluated according to DSL author's rules
for example, datomic queries are just data structures, but they clearly form a constrained language with well defined semantics and the fact that they're not implemented via macros doesn't make them less of a DSL
The caps/deps node/network looks very similar to Pathom Resolvers. Those also allow for parallel execution. I think it will be a huge project to recreate all the features (and robustness) that they have there. So far I've found their engine is quit sophisticated and robust. You can have very complex declarative models (it's a very weird inside-out way to write code, but the net result is very composable)
Just my unsolicited advice, but I'd try to build your system on top of their engine if you can. It's quite extensible. For instance they don't have "capabilities" but I think it'd be very easy to add that as a resolver key that's passed around.
If you want to install APKs directly on Android phones selling in China, you'll face even more draconian restrictions imposed by both Chinese OEMs and Chinese government, e.g., cannot install telegram [1], cannot install VPNs [2], called by local police station after installing VPNs [3], and so on. And you do not have the freedom to even talk about these restrictions freely without getting sued or censored.
If you're "building data system not just for exploratory" then you're probably not going to be using any of the presented options. However, in my experience Clojure has an ecosystem where there it is very easy to transition from exploring/playing with data at the REPL to a more robust "pro" setup that's designed to scale, handle failures, etc.
I understand the sentiments but I disagree with the approach, it's probably efficient for exploratory but not effective for everything else including prototyping and systems development.
For any engineering work, including software engineering you choose the best tool for the job. In D you can have the high performance tool capable of bit shifting, string processing, array manipulation (to name a few) and from scripts to highly concurrent low-latency applications (see presentation in the ref [3] above by Prof. Shah from Yale).
It's a shame that the proper typed programming language are being ignored just because of programmers' locally sub-optimal preferences and limited exposure. The productivity increased using typical scripting languages including Python is diminishing everyday with the proliferation of IntelliSense, auto-complete and AI assisted coding.
For production codes, the scripting language based systems if they ever made it to production (mostly do e.g AirBNB, Twitter, Shopify, Github, etc) will be a maintenance headache and user nightmare, if the supports are not great and not unicorn start-ups. The last thing you want is that your saved eclaim form that you spent many hours preparing totally dissapeared since the system cannot recall the saved version. Granted this can be because of many reasons, but most of the problematic production systems are mostly written in scripting languages including Python because these are the only language the programmers know and familiar with. Adding to the insults are the readily available so called "battery included" libraries are convenients but ironically written in other compiled but unsafe system language in C/C++.
I think you're going to trouble convincing people a compile-loop language is going to be on-par with a REPL/interactive setup. You can look at some extreme example like MATLAB. With all your tools you're never going to reach the same level of interactive productivity with D for the subset of problems it's address.
You can have all your tools dump out and rewrite the oodles of boiler plate your typed languages require - but at the end of the day you have to read all that junk... or not? and just vibecode and #yolo it? But then you're back to "safety and reliability" problems and you haven't won anything
Also "safety and reliability" are just non-goals in a lot of contexts. My shitty plotting script doesn't care about "safety". It's not sitting on the network. It's reliable enough for the subset of inputs I provide it. I don't need to handle every conceivable corner case. I have other things to do
> Adding to the insults are the available readily available libraries are convenients but ironically written in other compiled but unsafe system language in C/C++
No on cares if you leak memory in some corner case with some esoteric inputs. And noone is worried your BLAS bindings are going to leak your secrets. These are just not objectives
My point is that Dlang scales from beginner to expert, from scripting to highly concurrent low-latency applications. Why settle for sub-optimal scripting languages if you can have the real deal with much better performance and freely available open source?
In the automative world if you can afford it, you need daily drive car for the job and supermarket runs, weekend supercar for fun/showing off, and off-road 4x4 vehicles for overnight camping. But in the software world D can cater for mostly everything with free open-source compilers, minimum productivity overhead and much cheaper to host as well [1].
Funny you mentioned BLAS, since Dlang BLAS implementation has also surpassed the run-of-the-mill high performance BLAS library that these scripting languages can only dream of (Matlab calling the 3rd party Fortran codes no less) [2].
In my experience the advantage comes when you have a few more lines of code
The Clojure pipelining makes code much more readable. Granted dplyr has them too, but tidyverse pipes always felt like a hack on top of R (though my experience is dated here). While in Clojure I always feel like I'm playing with the fundamental language data-types/protocols. I can extend things in any way I want
great idea, we'll do that too. we just decided to launch an onnx first and get some feedback. we'll be simplifying the process of running it everywhere including a command line executable.
I'm pretty sure all of Clojure runs on Java 8, so if you use some new feature I'm guessing you need to provide a fallback - but you're also going to be running on Javascript and other platforms, so that's par for the course
Have you considered rotating the layout? I always though a CJK programming language written vertically would be very ergonomic. Instead of scrolling vertically the program would flow right-to-left or left-to-right. I guess you'd probably want to rotate the bracket/paran glyphs which is a bit less trivial to do
Presumably the idea is that you put the relevant parts of the list in your thesis. You need to convince your examiner that you understand the background to the original research you did, and a solid reference list (with supporting text in the introductory/background section of your thesis) is part of doing that.
Personally I did the references at the end and didn't feel like I suffered from that decision, but the key references in my particular area were a relatively small and well-known set.
Hmm, yeah. I mean you often see huge reference lists which always just makes me feel like the person can't possible be actually well acquainted with the stuff that's being referenced. So who are you really fooling? Seems all very performative, though I guess I understand the motivation
A good example is making GUIs in Clojure. At first there was a cool macro based system called `fn-fx` that maked a JavaFX GUI. Then vlaaad wrote `cljfx` which just used plain Clojure maps and removed the macros entirely. This increased the boilerplate a tiny amount but made the system much more flexible and extensible
reply