Nano Hash - криптовалюты, майнинг, программирование

Должен ли я использовать Java для пользовательского компонента Swing, разработанного для приложения clojure?

Мне нужен простой компонент временной шкалы (например, в программном обеспечении для редактирования видео) для приложения clojure/seesaw, и мне интересно, является ли это хорошим подходом для реализации этого непосредственно с помощью clojure и качелей или мне следует написать его на java и сделать свою оболочку clojure вокруг него.

Или, в более общем плане: является ли функциональный язык программирования оптимальным для написания виджетов пользовательского интерфейса? Я не могу представить себе это без участия государства. А разве объектно-ориентированный подход не был придуман для разработки пользовательского интерфейса в первую очередь?

clojure swing seesaw
23.03.2012

Ответы:


1

Вы могли бы пойти в любом случае. В Overtone мы создали ряд пользовательских графических компонентов непосредственно в Clojure с качелями. Во многих случаях для такого рода вещей достаточно атома и (seesaw.core/canvas).

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

Тем не менее, если вы хорошо разбираетесь в Swing/Java, вы можете сделать это там, и Seesaw будет совершенно счастлив работать с пользовательским виджетом, созданным на Java. Удачи!

23.03.2012
  • Использование атомов и холста было моим первым подходом, но когда взаимодействие стало более сложным, я начал создавать беспорядок. Рад слышать об обертоне и о том, что на самом деле есть примеры нестандартных компонентов качелей в качелях. 23.03.2012

    • 2

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

    23.03.2012
  • Спасибо. Я пойду по пути java здесь. Но FRP - интересный момент. Не слышал раньше. Я должен изучить это. 23.03.2012
  • Состояние само по себе не является причиной не использовать Clojure. Я считаю, что даже для чисто взаимодействия кода Clojure легче писать Java на Clojure, чем на Java. 23.03.2012

    • 3

    При прочих равных (т. е. при условии, что вы знаете и Clojure, и Java), я бы, вероятно, написал это как пользовательский компонент Swing на Java.

    Причины:

    • Swing по своей сути является ООП-фреймворком на основе Java и лучше подходит для Java с точки зрения парадигмы.
    • Изменяемое состояние проще в Java, чем в Clojure
    • Если вы пишете его на Java, вы можете легко использовать его в другом месте (например, в качестве библиотеки из другого кода Java).
    • Компонент Swing легко обернуть в Clojure после того, как вы его создали.

    Конечно, для самой логики приложения я бы, конечно, предпочел Clojure.

    23.03.2012
  • Спасибо за разъяснения. Я склонялся к использованию java для своей проблемы. Но, возможно, больше, потому что я новичок в clojure и чувствую себя намного комфортнее в java. 23.03.2012
  • Этот ответ не совсем верен. Изменяемое состояние для объектов Java в Clojure так же просто, как и в Java. 23.03.2012
  • @rplvy - конечно, вы можете использовать (set! (. objectExpr fieldName) expr), но даже в этом случае это менее удобно, чем objectExpr.fieldName=expr (особенно если учесть отсутствие проверки статического типа и необходимость подсказок типа, чтобы избежать отражения и т. д.). Кроме того, вы вообще не можете использовать изменяемые локальные переменные, которые очень полезны в коде ООП GUI. Как бы я ни любил Clojure, он не самый удобный для управления локальным однопоточным изменяемым состоянием. 24.03.2012
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..