?

Log in

No account? Create an account

Предыдущий пост поделиться Следующий пост
Реализация (NM – 1)-нашек
lex_kravetski
Для интересующихся выкладываю реализацию (NM – 1)-нашек на языке Wolfram. Сама постановка задачи описана вот тут.

До строки, начинающейся с «pos» — инициализация. Со строки «click» — интерфейс. Между ними «движок». Проверка выигрыша вписана в «интерфейсную часть» — в конец длинного «win».

Да, вся логика возможных перемещений и их реализация содержится в шести выражениях.

Примерно вот этим годные современные языки программирования отличаются от негодных и от несовременных: они позволяют сосредоточится на решении задачи, а не на соблюдении всех программистских ритуалов.



(NM-1)-нашки.png



  • 1
> Во-первых, вольфрам сильно платный

Это никак не относится к самому языку.


> Во-вторых, у вольфрама очень спецефичный синтаксис, этакий лишпик, он позволяет (и даже поощряет) писать неудобоваримый лапшекод, в котором через месяц без пол-литры не разберёшься.

Любой язык это позволяет. Гораздо более актуальный вопрос про каждый язык: позволяет ли он писать не так. И, таки да, Вольфрам позволяет.


> В-третьих, отстуствие нормальных библиотек или фрейморков, если мы конечно не говорим о всём, связанном с обработкой информации

Опять же, это не про сам язык. Это про комьюнити. Можно ли такие библиотеки написать? Да, можно. Написали ли их к данному моменту? Нет, не написали.


> В-четвёртых, маленькая популярность языка. Новых разработчиков найти будет очень сложно.

Это снова не про сам язык.


> В-пятых, адовый вендерлок. Если господин Стивен Вольфрам решит

Обратное обычно ещё хуже: совместимость с версией 1933-го года уверенно превращает язык в ходячего мертвеца.


> В-шестых, это специфический формат файлов исходного кода. Ни git, ни vcs с ними тупо не работают

Я сам не проверял, но мне это кажется странным: и записные книжки, и модули — текстовые файлы. С ними должно работать всё, что работает с текстовыми файлами. В том числе, должно работать сравнение версий, если оно работает для текстовых файлов.


В общем, если выбирать между Scala и Wolfram для этой задачи, я бы, конечно, выбрал Scala. Или даже Java 8. Но вот при выборе, скажем, между С++ и Wolfram, я бы выбрал Wolfram.

При условии, разумеется, того, что он вдруг стал бы бесплатным, но мы сейчас про языки, а не про условия их распространения.

Ну и, конечно, если бы для С++ движок уже был, а для Вольфрам — нет, то С++ для этой задачи бы выиграл, но это тоже не про сам язык. Это — про наличие 90% требуемого результата в готовом виде. В таких условиях даже Бейсик бы у Скалы выиграл.

> Это никак не относится к самому языку.
Так можно было бы говорить при наличии сторонних реализаций.

Мы же живём в реальном мире, в котором приходится учитывать не только красоту языка.

> Написали ли их к данному моменту? Нет, не написали.

И это большая проблема.

> С ними должно работать всё, что работает с текстовыми файлами.
К сожалению, при сохрании блокнота в файл Вольфрам генерирует и записывает массу лишней мета-информации вроде дерева ячеек (внутри дркумента на самом деле что-то типа DOM), кэшированных картинок и прочих сложно структурированных данных, из-за чего даже одна добавленная в исходный может сгенерировать пару килобайт добавочного мусора.

> Обратное обычно ещё хуже: совместимость с версией 1933-го года уверенно превращает язык в ходячего мертвеца.

В случае вендерлока (я напомню, альтернативных реализаций нет) параноидальная обратная совместимость гораздо меньше зло, чем одно ломающее изменение. Это уонечно не важно, если ваш код умещается на одном экране, но в случае более-менее крупной система приводит к катастрофе (тем более учитывая сложности с наймом новых разработчиков на этом языке)

> В таких условиях даже Бейсик бы у Скалы выиграл.

Разумеется. Поэтому я выберу бейсик для работы с excel документами, а не скалу.


Потому что язык - это прежде всего инструмент.

  • 1