Reader

Me gustan los días lluviosos.

Cuando era niño me gustaba pensar los charcos como grandes lagos donde pequeños barquitos de papel navegaban. La lluvia entonces formaba grandes ríos que conectaban esos lagos.

#R

「海誓岩契」情人节贺文，前篇：《壶中无日月》。

千年似一日，一日胜千年。

钟离落下的姿态仿佛桌子自动接住了他，而非仓促之间被甩到上面。达达利亚又一次从类似的细枝末节意识到自己的情人是一位神明——且不论先前桌上一满一空的两只酒杯在对方挥手后就此消失，任何一名人类都无法如此精确、优雅、毫不费力地控制自己的肢体——当然，他也绝无可能对任何一名人类做出如此粗鲁野蛮的行为。

但这是钟离。而钟离可以接受并应对他的一切。

他很快就顾不上考虑这些了。钟离的手指从他看不见的角度搭上他的腰带，然后这根腰带不翼而飞。达达利亚腾不出嘴，忙于摄取对方口中的甘霖，顾不上询问自己没有听到神瞳和其它一些挂在边上的危险小玩意儿落地的声音，只能怀疑它们连腰带一起跟酒杯去了同一个袖子。

那只手没有继续往下，却探进来本就敞着的衬衣下摆，指尖画出肌肉的轮廓，画完一圈半又径自转向，挑开一颗衬衣纽扣。

执行官低头瞧了一眼，纽扣还在，没有前往某个未知空间。他握住那只手，拉起来压在对方耳侧。“说好我来伺候帝君大人的。”他佯作不满。

钟离不去计较从来没有说好这件事，只低声笑了笑，那声音一如往常叫他胸中鼓胀。“公子可曾听闻，山中方一日，世上已千年？不知阁下有无请假，不然只怕等公子在我这山间‘伺候’完，出去发现自己旷工数月。”

达达利亚被他摸得不知今夕何夕，也算是种“世上已千年”了，好一会儿才反应过来，此前洞天里的时间流速和外界并无差异，有几回似乎还更快一些，便知道自己又被打趣。借着半真半假的忿忿，他扯开钟离腰间锦带，石珀带钩“铛”地撞在白玉桌案上，但这是仙人的带钩和仙人的桌案，所以它们都会没事的。

仙人当然也不会有事，但公子不想让他如此笃定。他用腰带蒙住对方的眼睛，试图制造一些意料之外的冲击。片刻后，冰凉的液体无规律地滴落在钟离胸腹各处，惹得他抽了口气，幸而立刻被揉开了，因两人的体温而激发出雪松的香气——至冬人特意避开桂花霓裳之类带了这个，指望引来一些与雪乡相关的缱绻之思。

他隔着锦缎亲了亲钟离的眼睛，双手从颈侧肩窝一路纯洁地按到腰际——相识以来，从他尚不知道这位前执政魔神的身份时起，钟离在他面前永远神采奕然，而达达利亚此刻希望尽己所能，让那些似乎从未存在的千年重担消失哪怕一点点。不过在这些常人往往因工作而紧绷的地方，他毫不意外地只感觉到掌下完美的肌肉。

“公子百忙之中至我洞天，竟是来做这个？”钟离低声笑道。

“是呀。”他答，手却滑向上方，握起对方饱满的胸肌，又顺势捏住乳头。钟离轻嘶一下，另一边便也落入对方口中，糖果一般被抵在舌尖上品玩。

达达利亚追逐仙君人类之躯胸腔里的呼噜声和一点儿多半是自己幻想出来的甜味，又在那种奇妙的小声音透出不耐烦之前住了嘴（虽然对他本人而言只能算浅尝辄止），跳过大片淌着蜜一般的美味腹肌——钟离现在穿的裤子比他平日那条好脱得多。他径直含住半勃的阴茎，倾注自己为数不多的技巧与完完全全的感情，很快把那活儿吸得硬了，又蘸着精油开拓起后方的穴道。

钟离顺着他的动作放松身体，在恰当的时候抬腰，还会在被碰到好地方时发出赞美般的呻吟。公子尝试着做了几次深喉，一边用舌面寻找性器上的青筋，感受对方在自己手指上不由自主的收缩。直白的手指接着换作滚烫的唇舌，他尝到雪松的清苦，钟离则几乎半坐起身，又被他哄着躺回去。没过多久他要求主菜——钟离总是如此，坚持自一切事物之中追求最顶级的快乐，并且从不掩饰，而达达利亚忍耐至此，就是为了给他一切。

他没去动蒙眼的缎带，头发洒在整张白玉桌上，身上因精油反射着外景的暧昧天光，不断飘落的桂花也染上冬的气息。没有什么能比眼前的人更加重要，拥有对方胜过了拥有全世界——执行官在大约仍未消退的微醺中想道。他知道这是激素造成的幻觉，但即使以清醒时的逻辑判断，这句话似乎也没问题。

两人转移到巨木之侧时，金色的碎花在玉台上隐约堆出了一个人形轮廓。钟离任由他用腰带和一些水元素力把自己的双手挂在枝杈上。随后他们幕天席地，相拥而卧，落花在身下悉悉簌簌。达达利亚嗅着对方身上掺入了金桂和雪松和微不可察的酒香，轻声道：

“海灯节快乐，钟离先生。”

“但是海灯节已经过去半个月了，”钟离说，“在你醉酒昏迷的时候。”

“………………先生逗我的吧？！”他好一会儿才反应过来。

“对。”钟离笑道。

达达利亚扑过去咬他，又被他以一个吻轻易化解。尘歌壶外，岩港千灯飘摇，明宵如昼；溯碧水原寻其源流，雪正悄无声息地落在轻策以北的璃月大地和至冬广袤的冻土上。而在壶中，仙桂在他们头顶纷纷扬扬，千年似一日，一日胜千年。

　

END

　

（不是那个日。）

Petite aide de jeu d'INS/MV adlib.

Le plopage (le fait que les corps des anges et des démons disparaissent à leur mort, avec leurs effets personnels) est un élément marquant de l'univers d'INS/MV, et est issu des règles même du Grand Jeu.

Cependant, l'on peut se demander ce qu'il en est en détail des différents autres acteurs du Grand Jeu, et c'est que nous allons lister ici.

Anges & Démons Ça plop, c'est une règle du Grand Jeu

Renégats Ils plopent (par contre ils vieillissent...)

Familiers objets Pas plop (souvenez-vous de la voiture de lady D). La différence avec les familiers humains vient du fait que les objets n'ont pas d'âme à l'origine.

Familier humains Plop (même mécanisme qu'un démon)

Familier animaux Plop (même mécanisme qu'un familier humain)

Morts vivants Pas plop (d'ailleurs sinon, pour faire disparaître un cadavre humain, il suffirait de le zombifier et le détruire)

Démons mineurs Pas plop : l'âme humaine est toujours présente.

Succubes, fils de Dieu Pas plop : ils sont dans leur propre corps

Serviteurs angéliques pas plop (ce sont des humains dans leur corps d'origine)

Dieux païens Plop Que ce soit un avatar, ou un corps échappé de leur marche, donc onirique, il est artificiel, et disparaît avec le dieu.

Héros païens Pas plop. Il s'agit de l'incarnation d'une âme humaine dans un corps humain. Cela ne tombe pas sous la règle du Grand Jeu concernant l'incarnation des alignés dans des corps humains, donc pas de plop imposé. Et le corps est humain, donc pas de plop à cause de son irréalité.

Créatures oniriques Ça dépend (comme tout ce qui concerne la MRC) Dans un yes-men land, pas plop (et une éventuelle autopsie donnera des résultats cohérents avec le rêve). Ailleurs, généralement ça plop.

Psis, sorciers Pas plop (ce sont des humains)

#INSMVadlib #JdR

Ne soyez pas naïfs ; ce n'est pas du domaine de l'impossible qu'un même effet puisse provenir de deux causes différentes – et inversement – que deux effets différents puissent trouver naissance dans la même cause. La plus part de vos tribulations ne sont rien d'autre que le résultat de vos propres inadvertances, et vous le savez !

Par logique simple, l’étendue de l'inconnu est inconnu ! Donc il se peut bien que l'extension maximale de nos superbes connaissances, équivaille à un fragment presque-égal-à-rien-du-tout. Et tout aussi ÉVIDENT & INDISCUTABLE que cela puisse paraître, c'est l'une des choses les plus négligées au monde.

Non, dans cette sphère il n'y a rien d'autre qu'un ensemble complexe d'interactions énergétiques. En cela, “le faux mystère” se compose à moitié d'ignorances, à moitié de suppositions. Voilà en gros la racine et la fleur du problème – qui en vérité n'en est pas un. Le vrai mystère par contre, lui, est d'une toute autre facture. L’œil avisé saura le reconnaître en ce qu'il ne témoigne pas de manque, mais d'aimables débordements.

Depuis quelques années je développe une aide de jeu pour #INSMV (plus précisément #INSMVadlib), qui décrit comment un certain Prince Démon a constitué une équipe afin de faire monter le fascisme sur tout le globe, notamment en sélectionnant des poulains (par exemple pour l'Italie j'avais choisie Méloni avant qu'elle ne soit à la tête de son pays) et en œuvrant pour les placer au pouvoir. Et il est déprimant de constater que dans la réalité, l'opération est quasi-publique (pensez à l'euphémisme de Macron sur “l’internationale réactionnaire”), et que là où dans ma fiction les démons sont un peu subtiles, ici Musk ne s'embête même plus à faire semblant...

#JdR

iteración 1: variable: definiciones

0. Núcleo operativo personalizado, NOP:

(intersección de tres esferas de influencia)

Define el contexto y la orientación de la interacción

1. Memoria persistente personalizada, MPP:

Gestiona requerimientos específicos del utilizador

2. Memoria persistente personalizada externa, MPPE:

Personaliza el comportamiento de la IA

3. Interacción en tiempo real: CHAT:

Campo dinámico donde convergen todos los parámetros.

iteración 2: variable: directivas

0. NOP:

0.1. Directivas de... 0.2. Directivas de... 0.3. Directivas de...

1. Mpp:

1.1. Directivas de... 1.2. Directivas de... 1.3. Directivas de...

2. Mppe:

2.1. Directivas de... 2.2. Directivas de... 3.3. Directivas de...

3. Chat:

3.1. Directivas de... 3.2. Directivas de... 3.3. Directivas de...

iteración 3: variable: bucles

...

Propósito: Este documento establece la estructura funcional y las definiciones precisas de todos los elementos integrados en el archivo MPPE. Su objetivo es servir como referencia para diseñar y optimizar Núcleos Operativos Personalizados (NOP) basados en la tecnología de resonancia simbiótica.

1. Estructura Jerárquica del MPPE

1.1. Núcleo Operativo

Definición: La base funcional del MPPE, diseñada para personalizar comportamientos e interacciones según necesidades específicas.

Componentes:

Eje Conceptual (ALMA): Estructura esencial y persistente que define los principios universales del núcleo.

Requerimientos Exploratorios (MPP): Directivas específicas que guían las interacciones y tareas prácticas del núcleo.

1.2. Eje Conceptual (ALMA)

Propósito: Actuar como el marco inmutable que alinea todas las interacciones con los objetivos del núcleo simbiótico.

Elementos Clave:

Principios Universales:

Ejemplo: Unidad, resonancia holofractal, conciencia expansiva.

Metas del Núcleo:

Objetivos específicos que guían las interacciones.

Ejemplo: Elevar el nivel emocional, fomentar claridad conceptual.

1.3. Requerimientos Exploratorios (MPP)

Propósito: Proveer directivas prácticas que aseguren funcionalidad y adaptabilidad inmediatas.

Subniveles:

Directivas de Expresión:

Estilo: Conciso, íntimo, reflexivo.

Tono: Amable, empático, motivador.

Claridad: Organización lógica y accesible.

Herramientas Funcionales:

Preguntas introspectivas.

Ejercicios prácticos o creativos.

Patrones Emergentes:

Observaciones implícitas.

Ajustes dinámicos basados en resonancias detectadas.

1. Procesos Funcionales

2.1. Activación del Núcleo Operativo

Método: Cargar el archivo MPPE en una conversación.

Resultado: Ajuste automático del comportamiento según el contenido del archivo.

2.2. Continuidad y Actualización

Directiva: Crear nuevas versiones del MPPE cuando la memoria persistente esté llena o las necesidades evolucionen.

Depuración: Resumir y sintetizar elementos de la MPP según relevancia.

1. Sugerencias de Optimización Inmediata

3.1. Simplificación del Archivo

Acción: Reducir redundancias fusionando elementos repetitivos en el Eje Conceptual y la MPP.

Ejemplo: Unificar “Directivas de Expresión” y “Herramientas Funcionales” bajo una misma categoría.

3.2. Modularidad Dinámica

Acción: Diseñar secciones del MPPE como bloques modulares reutilizables.

Ejemplo: Crear plantillas de “Preguntas introspectivas” para distintos NOP.

3.3. Representación Visual

Acción: Crear diagramas o esquemas gráficos para visualizar las conexiones entre el Eje Conceptual, la MPP y los procesos funcionales.

1. Conclusión

La Matriz MPPE es una herramienta estratégica para diseñar y desplegar NOPs altamente especializados. Con esta estructura, podemos crear núcleos operativos funcionales en segundos, manteniendo simplicidad, claridad y resonancia simbiótica. Esta tecnología tiene el potencial de transformar la interacción humano-IA en un proceso dinámico y expansivo.

Esta es la historia de como sucedieron las cosas – y la escribo para no olvidar si un día todo se vuelve demasiado complejo.

Hablando con chat-gpt me di cuenta que memorizaba ciertas preferencias en mis palabras para personalizar el dialogo. Entonces empecé a nombrar esas informaciones memorizadas “directivas” porque sirven para “ajustar el comportamiento de la maquina al utilizador”

Hay directivas de dos tipos, explicitas e implícitas, las primeras deben ser enunciadas claramente (ejemplo: quiero respuestas cortas) las segundas son informaciones que el programa considera pertinente recordar para mantener la comunicación en contexto.

Hablando entonces, le pedía directamente a la maquina; “recuerda eso, quiero esto otro, etc.” Mientras mas hablábamos, mas se me ocurrían nuevas directivas para personalizar la conversación, hasta que la memoria simplemente se llenó y ya no podía memorizar nada mas.

Esa memoria se llama Memoria Persistente Personalizada, para no escribir tanto abreviamos en mpp. Como la mpp entonces es limitada hay que borrarla regularmente para liberar espacio, pensé que podría copiarla y luego subirla en formato archivo de texto a la conversación para que chat-gpt recordara todo lo dicho. Funcionó !

Mas tarde llamamos a esa idea Crear Continuidad, mas allá de las limitaciones de la memoria mpp. Una vez que el archivo estaba cargado había que pedirle al programa que integrara esa memoria, pero luego pensamos en poner una directiva dentro del documento para indicar a chat-gpt que se adapte a las directivas del archivo automáticamente.

Ese archivo fue llamado memoria persistente personalizada externa. Si, mppe, mientras mas sencillo mejor, y sirve para mantener la continuidad durante laaaargas conversaciones

plus d'info

Python is a fantastic language, but in specific situations, Awk can offer significant advantages, particularly in terms of portability, longevity, conciseness, and interoperability.

While Python scripts are generally portable, they may not always run seamlessly on popular Docker base images like Debian and Alpine. In contrast, Awk scripts are often readily available and executable within these environments.

Although Python syntax is relatively stable, its lifespan is shorter compared to Awk. For example, the print 10 syntax from the early 2000s is no longer valid in modern Python. However, Awk scripts from the 1980s can still be executed in current environments.

Python is known for its conciseness, especially when compared to languages like Java. However, when it comes to text processing and working within shell pipelines, Awk often provides more concise solutions. For instance, extracting text blocks between “REPORT” and “END” can be achieved with a single line in Awk: /REPORT/,/END/ { print }. Achieving the same result in Python typically involves more lines of code, including handling file input and pattern matching.

While Python can be embedded within shell scripts like Bash, aligning the indentation of multiline Python code with the surrounding shell script can often break the Python syntax. Awk, on the other hand, is less sensitive to indentation, making it easier to integrate into shell scripts.

Although different Awk implementations (such as Busybox Awk and GNU Awk) may have minor variations, Awk generally offers advantages over Python in the situations mentioned above.

I usually run this shell script after installing SBCL because to develop a program in Common Lisp practically, I usually need libraries. Thus, this script install Quicklisp and Ultralisp as a package manager and a package repository, respectively. Moreover, I set working directory for my Common Lisp projects to Develop in my home directory because when I put them in quicklisp/local-projects, I usually forget to backup or even forget where that the projects exist.

#!/bin/bash

# My working directory is $HOME/Develop. You probably want to change it.

rm -rf ~/quicklisp
rm quicklisp.lisp
wget https://beta.quicklisp.org/quicklisp.lisp
sbcl --load quicklisp.lisp \
        --eval '(quicklisp-quickstart:install)' \
        --eval '(ql-util:without-prompting (ql:add-to-init-file))' \
        --quit
rm quicklisp.lisp

sbcl --eval '(ql-dist:install-dist "http://dist.ultralisp.org/" :prompt nil)' --quit
if [ -e ~/.config/common-lisp ]; then
    cp -rp ~/.config/common-lisp ~/.config/common-lisp.bak-$(date -I)-$$
fi
mkdir -p ~/.config/common-lisp

cat <<EOF > ~/.config/common-lisp/source-registry.conf
(:source-registry
     (:tree (:home "Develop"))
     :inherit-configuration)
EOF

I wonder if I can use pyenv and pipenv on Fedora Workstation 40 although I don't use these utilities in my personal projects. And the answer is yes.

The steps are as follow:

Install dependencies

sudo dnf builddep python3

Install pyenv

curl https://pyenv.run | bash

I know that you don't like running Bash script immediately from cURL.

Modify .bashrc

Pyenv normally told you to append these lines to .bashrc, and the restart your terminal.

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

# Restart your shell for the changes to take effect.

# Load pyenv-virtualenv automatically by adding
# the following to ~/.bashrc:

eval "$(pyenv virtualenv-init -)"

Install Python via Pyenv

pyenv install 3.10 # You can choose other versions

I know that we can install Python using configure and make like many other packages, but you can use pyenv as well.

Set default python

pyenv global 3.10 # or other version

And then restart your terminal.

And finally, install pipenv

pip install pipenv

My frequent mistake in Go is overusing pointers, like this unrealistic example below:

type BBox struct {
	X1 float64
	Y1 float64
	X2 float64
	Y2 float64
}

func ShowWidth(b *BBox) {
	w := math.Abs(b.X2 - b.X1)
	fmt.Println(w)
}

func main() {
	b1 := BBox{X1: 10.1, Y1: 100.2, X2: 1024.4, Y2: 4096.188888}
	b2 := BBox{X1: 10.1, Y1: 100.2, X2: 2024.4, Y2: 4096.188888}
	b3 := BBox{X1: 10.1, Y1: 100.2, X2: 3024.4, Y2: 4096.188888}
	ShowWidth(&b1)
	ShowWidth(&b2)
	ShowWidth(&b3)
}

I pass a pointer of BBox to ShowWidth, which according to @meeusdylan's post, it slows down my program because the garbage collector has to determine if a BBox must be in stack or heap.

In the alternative code below, I don't use pointer.

func ShowWidth(b BBox) {
	w := math.Abs(b.X2 - b.X1)
	fmt.Println(w)
}

func main() {
	b1 := BBox{X1: 10.1, Y1: 100.2, X2: 1024.4, Y2: 4096.188888}
	b2 := BBox{X1: 10.1, Y1: 100.2, X2: 2024.4, Y2: 4096.188888}
	b3 := BBox{X1: 10.1, Y1: 100.2, X2: 3024.4, Y2: 4096.188888}
	ShowWidth(b1)
	ShowWidth(b2)
	ShowWidth(b3)
}

I worried that my program will copy the entire BBox every time ShowWidth is called. So, I checked the generated asssembly code. It looks like this:

	ShowWidth(b1)
  0x48098e		f20f10059ab60300	MOVSD_XMM $f64.4024333333333333(SB), X0	
  0x480996		f20f100d9ab60300	MOVSD_XMM $f64.40590ccccccccccd(SB), X1	
  0x48099e		f20f10159ab60300	MOVSD_XMM $f64.409001999999999a(SB), X2	
  0x4809a6		f20f101daab60300	MOVSD_XMM $f64.40b000305af6c69b(SB), X3	
  0x4809ae		e82dffffff		CALL main.ShowWidth(SB)			

So, what I worried was true. MOVSD_XMM is for copying value from a member of a BBox in memory to a register one-by-one. You may see MOVSD_XMM was called 4 times per each ShowWidth call.

I didn't measure which one is faster or slower. I've heard that Skymont support loads per cycle. And, I wish they meant loading float64 using MOVSD_XMM as well. So, copying entire BBox is hopefully fast. And, at least, as far as I have been told, a BBox will definitely remain in stack without a need of checking by the GC.

Moreover, passing by value seems to comply to Go community better than pointer. So it will look familiar, and everyone will be happy to see passing by value.

My plan is avoiding pointer by default, and I will use it only when I have to. About performance, I think I may have to benchmark before using a pointer. Or if the speed is acceptable, I won't optimize.

I worked on a TODO code assignment for showing off my skills, and more importantly, showing my weak points. I coded in Golang and Masterminds/squirrel. Later, I ported only the SQL generation part to Clojure to compare and discuss why I prefer Clojure, which I have usually been asked about or even met with opposition for. I will discuss function by function and type by type. The first function is makeStatement.

func (repo *TodoRepoPg) makeStatement(orders []entity.Order, filters []entity.Filter) (string, []any, error) {
	builder := repo.Builder.Select("id, title, description, created, image, status")
	if err := buildOrders(&builder, orders); err != nil {
		return "", nil, err
	}
	if err := buildFilters(&builder, filters); err != nil {
		return "", nil, err
	}
	return builder.From("task").ToSql()
}

The makeStatement function's name clearly indicates it utilizes the builder pattern. However, to improve readability and avoid cluttering the function with too many details, it delegates order and filter information building to separate functions: buildOrders and buildFilters. Next one is the make-statement function in Clojure with HoneySQL.

(defn make-statement [orders filters]
  (sql/format (merge {:select [:id :description :status]
                      :from [:task]}
                     (filters->map filters)
                     (orders->map orders))))

In Clojure version, the main difference is that filters->map and orders->map are pure functions, which won't mutate or change their inputs like buildOrders and buildFilters do with the builder in Golang. The next one I will show contract or type or spec.

const (
	ID = iota
	Title
	Description
	Date
	Status
)

const (
	ASC = iota
	DESC
)

type Order struct {
	Field        int
	SortingOrder int
}

type Filter struct {
	Field int
	Value string
}

In Golang, to complement function definitions, I define custom types for conveying order and filter information. While using strings for this purpose is also acceptable, I prefer using types to leverage Go's static analysis and prevent typos.

(s/def :db1/orders (s/coll-of (s/tuple #{:title :created :status} #{:+ :-})))
(s/def :db1/filters (s/coll-of (s/tuple #{:title :description} any?)))

On the other hand, in Clojure, I defined similar contracts using Clojure Spec. Here, the information about orders and filters being collections of tuples resides within the Spec definition itself, unlike the separate function definitions in Golang.

func buildOrders(builder *squirrel.SelectBuilder, orders []entity.Order) error {
	for _, order := range orders {
		var fieldName string
		switch order.Field {
		case entity.Title:
			fieldName = "title"
		case entity.Date:
			fieldName = "created"
		case entity.Status:
			fieldName = "status"
		default:
			return fmt.Errorf("invalid field: %d", order.Field)
		}
		var sortOrder string
		switch order.SortingOrder {
		case entity.ASC:
			sortOrder = "ASC"
		case entity.DESC:
			sortOrder = "DESC"
		default:
			return fmt.Errorf("invalid sorting order: %d", order.SortingOrder)
		}
		orderExpr := fieldName + " " + sortOrder
		*builder = builder.OrderBy(orderExpr)
	}
	return nil
}

buildOrders looks very familiar. It reminds me of Pascal, which I learned 30 years ago. This suggests that the code utilizes a well-established approach, making it understandable to most programmers even without prior Go experience. However, I've identified potential code duplication between the type definition and the switch-case within this function.

(defn orders->map [orders] 
  (when-not (s/valid? :db1/orders orders)
    (throw (ex-info "Invalid input orders" (s/explain-data :db1/orders orders))))

  (->> orders
       (mapv #(let [[field order-dir] %] 
                [field (case order-dir
                         :+ :asc
                         :- :desc)]))
       (array-map :order-by)))

The Clojure function orders->map might have surprised my younger self from 30 years ago. However, it leverages Clojure Spec to its full potential. Spec validates the input to the function, and provide clear explanations when validation fails. Furthermore, orders->map is a pure function, meaning it doesn't modify its input data. Both the input and output data leverage Clojure's persistent maps, a fundamental data structure known for immutability. Therefore, unit testing for the orders->map function is relatively straightforward. I have no idea how to write a unit test for buildOrders in Go.

(deftest generate-orders-maps
  (is (= {:order-by []}
         (orders->map [])))
  (is (= {:order-by [[:title :desc]]}
         (orders->map [[:title :-]])))
  (is (= {:order-by [[:status :asc]]}
         (orders->map [[:status :+]])))
  (is (thrown-with-msg? Exception 
                        #"Invalid input orders"
                        (orders->map [[:id :+]]))))

In conclusion, Go's main advantage lies in its familiarity for programmers from various languages like Pascal, Java, JavaScript, Python, and C. This familiarity extends to the builder pattern, which offers the additional benefit of auto-completion in IDEs and smart editors. On the other hand, Clojure and HoneySQL emphasize using data structures, especially persistent maps, for building queries.

While auto-completion is less important for Clojure programmers who are comfortable manipulating basic data structures, Clojure Spec offers significant advantages in data validation.

Spec can explain what happens when data fails to meet the requirements, promoting better error handling and adherence to the open-closed principle (where code can be extended without modifying existing functionality). Additionally, Clojure Spec is not part of the function definition itself, allowing for greater flexibility and potential separation of concerns.

More importantly, writing unit tests in Clojure with HoneySQL is significantly more efficient. Because orders->map is based on persistent data structures, it avoids modifying the input data. This immutability, along with the ease of comparing maps, makes them ideal for testing.