Есть ли какая-либо земля Haskell -, эквивалентная земле Ruby -& #39;s Bundler et. al, а если нет, то как можно было бы придумать проект с такой структурой?
Примечание для читателей:Потерпите меня. Обещаю, есть вопрос.
Мне нужно решить проблему, и я думаю: «О, я сделаю это на Ruby».
$ bundle gem problemsolver
create problemsolver/Gemfile
create problemsolver/Rakefile
create problemsolver/.gitignore
create problemsolver/problemsolver.gemspec
create problemsolver/lib/problemsolver.rb
create problemsolver/lib/problemsolver/version.rb
Initializating git repo in /tmp/harang/problemsolver
Удалите комментарий к s.add_development_dependency "rspec"в problemsolver/problemsolver.gemspec, а затем
$ bundle exec rspec --init
The --configure option no longer needs any arguments, so true was ignored.
create spec/spec_helper.rb
create .rspec
Новые тесты идут в spec/и должны быть в файлах, оканчивающихся на _spec.rb. Например,spec/version_spec.rb
describe 'Problemsolver' do
it 'should be at version 0.0.1' do
Problemsolver::VERSION.should == '0.0.1'
end
end
Для запуска спецификаций --игнорирование кода -изменение бегунов, таких как guard--тривиально:
$ bundle exec rspec
.
Finished in 0.00021 seconds
1 example, 0 failures
Вы не можете видеть это, но сообщение красиво закодировано цветом для быстрого Я облажался?" сканирование? Что очень хорошо в этом:
- Настройка была быстрой, почти безмозглой (, хотя выяснить, какие команды вызывать, не так уж и просто ).
- Стандартизированное расположение исходного дерева сокращает период ознакомления с новой кодовой -базой,упрощая совместную работу и сокращая время ожидания при выборе проекта, который вы ненадолго отложили.
- Сильная зависимость от инструментов распространяет передовой -опыт в сообществе примерно со скоростью создания нового проекта.
Добавление инструментов покрытия, наблюдателей за кодом, линтеров, инструментов тестирования поведения и других не сложнее.
Это выглядит невыгодно по сравнению с ситуацией, когда кто-то думает: «О, я сделаю это на Haskell».
$ mkdir problemsolver
$ cd problemsolver/
$ cabal init
Package name [default "problemsolver"]?
Package version [default "0.1"]? 0.0.1
Please choose a license:
1) GPL
2) GPL-2
3) GPL-3
4) LGPL
5) LGPL-2.1
6) LGPL-3
* 7) BSD3
8) MIT
9) PublicDomain
10) AllRightsReserved
11) OtherLicense
12) Other (specify)
Your choice [default "BSD3"]?
Author name? Brian L. Troutwine
Maintainer email [default "brian@troutwine.us"]?
Project homepage/repo URL?
Project synopsis? Solves a problem.
Project category:
1) Codec
2) Concurrency
3) Control
4) Data
5) Database
6) Development
7) Distribution
8) Game
9) Graphics
10) Language
11) Math
12) Network
13) Sound
14) System
15) Testing
16) Text
17) Web
18) Other (specify)
Your choice? ProblemSolver
ProblemSolver is not a valid choice.
Your choice? 18
Please specify? ProblemSolver
What does the package build:
1) Library
2) Executable
Your choice? 2
Generating LICENSE...
Generating Setup.hs...
Generating y.cabal...
You may want to edit the.cabal file and add a Description field.
«Отлично, — думаете вы, — я был так измучен, что могу поспорить, что все последние передовые -методы разработки программного обеспечения на Haskell только и ждут на моем диске».
$ ls
LICENSE problemsolver.cabal Setup.hs
Позвольте мне резюмировать мои чувства.::(
В сгенерированном файле клики нет даже Mainуказанных, не говоря уже о инструкциях по настройке рудиментарного проекта. Тем не менее, хорошо. Если вы немного попотеете, пытаясь найти правильные ключевые слова для поиска, вы попадете на Как написать программу на Haskell , что нормально, за исключением:
- Весь исходный код Haq кидается в корневой каталог.
- Тестовый код для Haq есть только в
Test.hs, только в QuickCheck и не имеет средств для продолжения проекта с разделенными -файловыми тестами. - Все это приходится вручную писать или копировать для каждого нового проекта.
Изучив Главу 11 Real World Haskell, вы обнаружите, что в ней даже не упоминается клика и полностью обходит вопрос о структуре проекта. Ни один из ресурсов, на которые Дон Стюарт любезно отвечает здесь , не упоминается ни в одном из вышеупомянутых, и, замечу, г-н Стюарт не объясняет , как использовать любой из упомянутые инструменты.
Обратите внимание, что принятый ответ в Рабочий процесс тестирования Haskell ссылается на проект, который с тех пор продвинулся в достаточной степени, чтобы не быть хорошим ответом, но действительно говорит
Поскольку тест клики не t еще не существует --у нас есть студент, работающий над ним для лета кода этого года!--лучший механизм, который у нас есть, — это использовать механизм пользовательского крючка клики.
Эй, хорошо, документация клики! В соответствующем разделе есть примеры, но они ужасно надуманы, но не перестают создавать впечатление, что каждый сам по себе, и удачи вам.
Конечно, всегда есть тестовая -структура , которая кажется хорошей, но код примера не предлагает ничего, кроме того, что можно увидеть в вики, и не является -масштабируемым в том смысле, что как только моя программа усложняется, я начинаю разрабатывать способы разделения тестов на управляемые модули. Я даже не уверен, что происходит с HTF , и согласен с оценкой г-на Волкова .
Г-н Джелвис 'комментарий к связанному вопросу HTF представлял для меня особый интерес :цепочка инструментов Haskell -очень сильно страдает от тирании мелких решений. На самом деле я не могу приступить к решению моей задачи --на Haskell --, потому что я на крючке для того, чтобы моя среда была только правильной. Почему это плохо:
- Это напрасные усилия. Если я не пишу тестовый инструмент, меня очень, очень редко будет волновать, как мои тесты хлюпают, только из , где .
- Трудно учиться. Кажется, не существует единого ресурса для создания проекта с встроенным тестированием, а различные существующие источники достаточно разнообразны, чтобы быть бесполезными.
- Трудно воспроизвести. С таким количеством движущихся частей, которые нужно аранжировать, я обязан делать это каждый раз по-новому.
- Как следствие, это своеобразно. Это означает, что трудно сотрудничать и поднимать бездействующие проекты.
Это просто воняет.
Хотя, возможно, я ошибаюсь. Существует ли какой-нибудь плохо разрекламированный инструмент или тщательно разработанные инструменты, которые делают что-то похожее на Bundler+Rspec в пространстве Haskell? Если не,есть ли плохо разрекламированный канонический пример современного тестирования Haskell со всеми упомянутыми вкусностями мистера Стюарта, испеченными прямо внутри? Проект, созданный или продемонстрированный :
- , должен по соглашению и инструментарию отделять тестовый код от кода приложения хорошо -определенным образом (на Ruby -, тесты Rspec идут
spec/, функции Cucumber вfeatures/), - не должны требовать от конечных -пользователей компилировать и устанавливать тестовые зависимости
- должны быть легко воспроизводимы, желательно не более чем за 10 минут и
- должны быть стандартизированы или иметь надежду на стандартизацию.
Не ошибаюсь ли я, полагая, что в стране Хаскелла -нет ничего подобного?
Edit0 :Обратите внимание, сообщество языка Ruby — не единственное применимое сравнение. Пол Р. прав, определяя сильное течение конфигурации над условностью. Другие языки решают проблему получения масштабируемой структуры проекта с нуля другими способами:
- C ::Этот язык почтенный и настолько хорошо -документирован, что вам будет трудно понять, какой хорошо -документирован подход. брать. Инструмента как такового нет.
- Java ::Конфигурация выше соглашения :вы привязаны к ней на уровне компилятора. Многие инструменты и очень хорошо документированы.
- Scala ::Мощная поддержка инструментов.
- Erlang ::Почтенный и слабо задокументированный, если вы знаете, что ищете. Возможно, конфигурация пренебрегает соглашением, если вы используете арматуру или иным образом ориентируетесь на OTP.
Решение Пола Р. по использованию пользовательского шаблона прекрасно работает, если, как и в C, имеется достаточно документации для его компиляции. Это по-прежнему сталкивается с проблемами, которые я пытался явно указать в сообщении, но это работоспособно.Лучшее предложение Haskell --, о котором я знаю --, — это «Как написать программу на Haskell», но оно не является чем-то большим, чем эквивалентом того, чтобы сбросить одинокого детёныша разведчика в лесу с фонариком и флягой. вода.
Кроме того, да, статические типы прекрасны и решают многие проблемы, которые в противном случае потребовали бы явного тестирования. Если бы они были окончательным -решением для всех или даже в основном достаточным, защелкивающаяся -структура не подвергалась бы столь тщательному тестированию. (Возможно, «Копировать оснастку -ядро». является ответом на мой вопрос.)