UVviewsoft forums

Решил завести отдельную тему, что бы не оффтопить в другой теме и не засорять форум.

Почему для CudaText вы выбрали паскаль? Я не знаю этот язык и его специфику, поэтому мне не очевидно.

Не знаю что это за язык, но получилась программа очень быстрой, а при этом ещё и судя по сорсам есть какой-то интероп с питоном. Почему вы не выбрали например C++ и Qt?

Я спрашиваю об этом не потому что мне что-то не нравится, а что бы прояснить выбор паскаля, потому что я не знаком с языком и в моём представлении это какой-то не мэйнстримный язык и из-за этого есть опасения что под него не достаточно много готовых библиотек, а значит развиваться продукт будет медленнее чем мог бы при использовании других технологий, как например си языки.

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

> Почему вы не выбрали например C++ и Qt?
Потому что я Делфист, паскалист, и С++ я просто очень не люблю, даже в ВУЗ с трудом писал лабы.

А если будет такая потребность, то сможет ли код паскаля использовать сишные библиотеки?
Например, если тот чувак будет слишком долго писать LSP, сможет ли проект взять рандомную быструю C++ реализацию и засунуть в проект?

Ну это просто пример, не LSP так что-нибудь ещё, что долго нельзя будет найти, а писать самостоятельно слишком сложно или слишком долго

не сможет. потому что надо собирать под Н процессоров и ОС. на питоне писать LSP support plugin не ОК, потому что АПИ не дает async function calls.

uvviewsoft wrote:не сможет. потому что надо собирать под Н процессоров и ОС. на питоне писать LSP support plugin не ОК, потому что АПИ не дает async function calls.

Понятно. Тогда я бы на твоём месте хотя бы подумал о плюсах и минусах перехода на c++ или любой другой быстрый мейнстримный язык с нормальным GUI фреймворком.

Чисто из прагматических соображений о том, что в будущем может появиться задача, решение которой есть в мейнстримных языках, но нет в паскале, а её решение либо само по себе сложное, либо что бы поддерживать это самостоятельно, требуются очень большие ресурсы.

Кстати, этот плагин обязательно должен быть монолитно впилен? Это нельзя реализовать как сервис? Запускаем отдельный процесс на абсолютно любом языке, в него отправляем штуки для анализа, а он указывает что делать и мы выполняем.

нет, проект не будет переписываться ни на чем еще.

> Это нельзя реализовать как сервис?
может и можно. если ты напишешь этот сервис то я подумаю как к нему подключаться. FPC имеет либы для http.