🚀 go-pugleaf

> > myDistance[s1_, s2_] := Total[
> >   Min[#] + Max[#] & /@
> >    Cases[SequenceAlignment[s1, s2], a_List :> StringLength /@ a]
> >   ]
> > 
> > Pozwoliłem sobie użyć skróconych (idiomatycznych) zapisów na podstawowe operacje mapowania i lambdy - skoro w innych językach są śmieszne znaczki, to ja też skorzystam.
> 
> No właśnie, i to mi się nie podoba.

Nie mam z tym problemu. Interpunkcja w Wolframie nie jest bardziej rozbudowana, niż powiedzmy w C++ a dla purystów (lub, co ważniejsze, automatycznych parserów i generatorów) wszystko ma dostępną tzw. pełną formę, zgodną ze schematem head[e1,e2,...].
Czyli idomatyczny zapis zawierający lambdę i mapowanie, np.:

#^2& /@ {1,2,3,4}

jest równoważny:

Map[Function[x, x^2], {1,2,3,4}]

ze spodziewanym wynikiem {1,4,9,16}.

To jest też zaletą Wolframa w stosunku do innych języków, które takich ustandaryzowanych zapisów nie umożliwiają i wymuszają swoją mniej lub bardziej cyrkową interpunkcję każdemu, kto tego języka używa. Ja w Wolframie mam wybór i stosuję skrócone zapisy tam i w takim zakresie, w jakim uznaję to za użyteczne. Ocena zależy też od tego, jaką żywotność ma mieć kod - projekt dłogofalowy i eksperymenty "na kolanie" to dwie różne sprawy (powyższy przykład to oczywiście ta druga kategoria). Fajnie, że Wolfram potrafi się dopasować do obu tych zastosowań.
Warto też zauważyć, że przy programowaniu w stylu funkcjonalnym wystarczy tylko kilka skrótów (lambda, mapy, transformacje), żeby spektakuralnie wpłynąć na ilość pisanego kodu. Te kilka skrótów to idiomy, które pojawiają się regularnie w dokumentacji i przykładach Wolframa, więc ich znajomość zdobywa się bardzo wcześnie. To nie jest poziom ekspercki.
Zobacz na pierwsze dwa przykłady tutaj:

https://reference.wolfram.com/language/ref/Map.html

Nie da się znać jednego i nie znać drugiego. To jest tak jak mała i wielka litery 'a' oraz 'A'.

> > Czyli nadal nie wyszło jakoś dramatycznie dużo tego kodu, prawda?
> 
> Nie wyszło. Ale nadal wyszło mniej, niż powinno.

A kto decyduje, ile powinno? Mathematica jest narzędziem wysokopoziomowym.

> Jeżeli jest użyteczny, to super. Ale mam nadzieję, że teraz lepiej rozumiesz moją perspektywę i niechęć do środowisk programistycznych o zamkniętym kodzie.

Wręcz przeciwnie. Rozumiem jeszcze gorzej, bo nie pokazałeś żadnej wady takiego rozwiązania. W Mathematice mam dostępne wszystkie opcje: mogę sięgnąć po gotową funkcję gdy chcę mieć od ręki gotowy wynik lub samemu napisać sobie algorytm, gdy chcę się wykazać rozumieniem tego jak działa. W tym drugim przypadku mogę stosować zapisy o różnym poziomie rygoru składniowego, żeby osiągnąć oczekiwane właściwości kodu. We wszystkich przypadkach jest albo krócej albo czytelniej (albo oba!), niż w dyskutowanych tutaj alternatywach.

Która z tych cech ma u mnie powodować "niechęć do środowisk programistycznych o zamkniętym kodzie"? Bo ja na skutek naszych dyskusji tylko się utwierdzam w przekonaniu, że Wolfram to bardzo dobra inwestycja.

> Zresztą moim ideałem jest, żeby to kompilator szukał za mnie gotowych implementacji, żebym mógł korzystać z gotowych optymalizacji, które ktoś zrobił za mnie.

Ale przecież napisanie własnego algorytmu jest tu utrudnieniem, bo odwraca uwagę kompilatora od właściwego celu. Rozwiązaniem jest właśnie zestaw funkcji wysokopoziomowych - takich jak EditDistance czy inny SequenceAlignment. Tam są te optymalizacje, z których chcesz skorzystać.

Tzn. ja chcę. :-)

-- 
Maciej Sobczak * http://www.inspirel.com