А есть ли хоть какие-то преимущества у C++Builder перед Delphi для Windows-разработки?
Если рассуждать в принципе, то таких преимуществ одно - это возможность использовать АПИ напрямую, без его заново. Это касается как самого виндового АПИ, так львиной доли сторонних библиотек, т.к. процент чего-то стоящего написанного на паскале, в сравнении с С - незначителен.
Если же рассматривать только создание приложений, где полностью хватает функционала VCL, то преимуществ я не вижу. Только архитектурные, связанные с различиями языков в принципе.
был бы конвертирован в Delphi, вы бы предпочли с ним работать, или остались бы с C++?
Это два разных языка. Рассматривать переход с одного на другой разумно только если один из них предоставляет какие-то средства, вообще не реализуемые в другом.
К примеру, в свое время одним из критериев перехода на С для меня стала практически полная невозможность в паскале использовать ни ассемблер, ни код из С. Т.е. в те времена, если под что-то не было TPU (то что в дельфи DCU), то ты не можешь это реализовать практически никак. А в те времена как раз играли в видео с прямым доступом к памяти, перекодировали тектовый кодогенератор, чтобы сделать "графическую мышь в тексте", пимали резидентов и прочее.
Сейчас возможность средств различается не принципиально. Да и язык этот мне уже не нравится. Меня бесит подход "один класс - один файл". С ужасом смотрю на компоненты дельфи, пипа инспектора объектов, котрые занмают мегабайт одним файлом. Я так думать уже разучился :)
Правильно помнишь. Еще оба эти компилера были первыми, котрые имели серьезную, шокирующую по тем временам, оптимизацию кода.
Семантик запомнился еще тем, что имел уникальные библиотеки, для той же графики, математики и писания резидентов, когда ризидентом висело только ядро, а вункционал подгружался при импользовании.
Можете привести определение безопасности, которому соответствует эта ошибка и пример кода, в котором она является небезопасной?
Приведенный у вас код не имеет отношения к обсуждаемому.
Второй вопрос: какой процент "ложных срабатываний" ошибки приемлем для комфортной работы?
Т.е. в каком проценте случаев возникновения этой ошибки код, на котором она возникла, не будет иметь никакого отношения от той "опасности" от которой она защищает.
Эти "пара кликов" займут 0.0001% времени в задаче "понять куда, как и когда их надо воткнуть".
Я подозреваю, что задачами по адаптации чужого кода, написано непойми как хз сколько лет назад, без коментариев и, возможно, даже без исходников Вы если и занимались, то не часто.
Просто поверьте, что тупое втыкание аннотаций к чужому коду может привести к проблемам по крайней мере не менее сложным чем "дебажить нпе в продакшине"
Во-первых, у котлина есть автоматическое создание доступа к элементам описанным в лайауте (т.е. создавать переменные в классе вообще не нужно).
Во-вторых, в андроиде есть дизайнер.
В свифте дизайнер(ы) напоминают "жалкое подобие левой руки" и, как правило, весь инерфейс создается в рантайме полностью вручную.
В-третих, из-за наличия дизайнера, в коде под андроид вы оперируете УЖЕ созданным интерфейсом и, соответственно, в активити\фрейме… можно использовать любой способ доступа к элементам (в том числе вручную lazy, если вас устраивает безумный оверхед на классах для каждой анонимной функции). При ручном создании интерфейса этим "лейзам" просто неоткуда брать компонент, поэтому используются всякие аналоги вида "firstAssign", но их не всегда удобно использовать.
Поняли правильно, но я там дальше написал использование.
Это не то.
Это глобальный ключ.
Я не хочу отключать проверки во всем проекте, без возможности указать его действие для модуля он для меня бесполезен.
Можно указать раздельные ключи индивидуально для каждого файла в IntelliJ?
Насколько я понял этот ключ делает не то что я хочу.
Он убирает оверхед проверок, а мне нужно другое: а) отключить исключение из smart-cast для var и б) временно выключить ошибки преобразования, т.е. временно интерпретировать типы не как "?", а как "!", что позволит мне оперировать nullable без огорода "!!" в коде.
Получается, что то что я написал выше: java-языкХ-java — это вполне правильно.
Языков JVM, которые бы не позволяли вызвать ява-код и быть вызванными из него не существует.
А то что типы могут потеряться и и тому подобное — это уже не принципиальные особенности т.к. они логически обоснованы разными языками.
Ясно.
Ты серьезно считаешь, что работу с миллионом существующих библиотек Java я долен начинать с их реверс-инжиниринга в попытках понять как они работают и чем чревато их использование с последующей их модификацией наружними аннотациями?
Ты сам-то так пробовл делать?
Сколько времени остается на ту работу за которую платят зарплату?
Чегож вы все читаете не то что написано, а то, на что знаете ответ?...
Где написано что нулевые типы в котлин — это плохо?
Где написано что я не понимаю откуда берется null?
Претензии к текущей реализации 2:
Ошибка компиляции, исключение из случаев safe-check, фактическая польза от которой, на практике, составляет мизерную часть тех мест в которых ее выбразывает компилятор, а во всех остальных она вызывает только раздражение.
То, что все эти проверки НЕ РАБОТАЮТ с данными, пришедшими из жавы!
А далее можете цитировать себя сами со всем обилием возможных проблем.
Вот пример именно Ваших слов с последствиями.
fun Dispatch( obj:GuiObject) {
... // тут будет проверка параметра на null
}
Dispatch( JavaCodeClass.getCurObject() ) // Тут проверки НЕ будет
В текущей архитектуре код хлопнется на проверке парамеров внутри "Dispatch" в РАНТАЙМЕ, т.е. все танцы с "?" и "!!", которые я вынужден использовать в исходниках, оказываются совершенно бессмысленными.
Это всего лишь кратенький пример иллюстрация.
Обойти в нем использование "!!" можно несколькими способами.
Но в реальной жизни, к сожалению, не все они удобны или применимы.
К примеру, при работе с интерфейсом swing в одной функции может происходить общение с кучей элементов интерфейса, каждый из которых nullable и с ним производится всего 1-2 действия.
Ни оборачивать каждый элемент в лямбду, ни заводить локальную переменную для них не имеет никакого смысла — это просто хуже читаетя и занимает больше места.
Приходится городить кучи "!!" в местах, которые гарантированно не null при использовании.
Это достает, вплоть до написание глобальной аннотации к классу.
Огромное спасибо за отклик.
Рад что одиозное название не отпугнуло от чтения
В данном случае, как в аббревиатуре RTFM, ругательная часть просто является обозначением, а не моим отношением :)
К сожалению, мой английский заточен на общение и кино, а написание довольно абстракных технических вопросов и пояснений мало того что отнимает огромное количество времени, так еще и, скорее всего, вызывает недоумение, поэтому многие вещи, которые хотелось бы иметь или о которых хотелось бы спросить я уточнить на форумах Kotlin не могу.
Пользуясь случаем хотелось бы обратить внимание на такие возможности:
Добавить компилятору ключи командной строки, которые бы могли влиять на его поведение. В настоящее время ключей практически нет, но их использовани могло бы решить некоторые частные вопросы. Например ключ для отключения механизма null-safety был бы часто полезен.
Во многих языках есть удобная фича: возможность указать ключи (или настройки компиятора) прямо в исходных текстах. Например в С для этого существуют pragma. Использование таких конструкций позволяет локально менять настройки и действует на весь модуль что в яве аннотациями не сделать, насколько я понимаю.
В результате этих двух пунктов можно было бы вынести какой-то код в отдельное место и указать для него другие правила (например отключить тот же null-safety, который при работе с каким-нить свингом просто мозг выносит т.к. превращает исходник в забор из "!").
Из scala вызов такого метода с тремя аргументами аргументами типа String становится ошибкой компиляции
Во!
В Kotlin точно так же.
Я пытался написать плагин к JavaDOC и вызвать явовский парсер из Kotlin не смог вообще. Именно из-за обилия перегруженных функций с одинаковыми типами параметров (куча форм вызова main с передачей ей строковых параметров).
Это только слова, к тому же без уточнения "non-private" еще и неправильные (и это без учета JvmField).
Во всех случаях кроме наличия обоих get\set в классе будет поле.
Я не помню, но вроде и с protected-ом будет protected поле, которое будет использоваться напрямую в родном классе и наследниках.
Еще раз: зачем приводить бесполезные ссылки?
Поверьте, я читал 99% документации, благо ее не вагон.
Фактическое поведение компилятора сложнее 3х строчек описания
Мы же вроде про мобилки, а там iOS. МacOS это "гуй на линуксе" или я все перепутал?
Впрочем, бог с ними.
Любые рассуждения на тему могут\будут\почему все равно голимые домыслы, которые еще и к теме статьи отношения не имеют :)
Т.е. существуют языки, в которых невозможно устаномить listener для класса на Java?
Если это так, то спасибо, не догадывался.
А какая ниша применения у такого рода языков?
Я цейлон не изучал, но на их сайте указан таргет JVM и в описательной части приведены примеры для использвания с Java EE. Прямые их примеры использования жавы тут: https://github.com/ceylon/ceylon-examples-jdk
Как это может работать без совместимости с Java?
Любой JVM язык полностью совместим с жавой. По определению :)
Вообще, ассемблер JVM крайне примитивен и, если бы в него, в свое время, конструктивно не были бы воткнуты всякие "хаки" для ускорения, то для него можно было бы собрать вобще любой язык, с любыми произвольными возможностями. Т.к. основной задачей любого JVM языка является совсем не поддержка этого ассемблера, а обеспечение точного и однозначного вызова java-языкХ-java, то все они абсолютно одинаково с ней "совместимы": генерируют точно такие же классы, неотличимые в среде выполнения от сгенерированных жавой.
С "доложить рантайм" понятно, но стимула делать это у гугла я пока не вижу. С апле ситуация другая совсем. У них крошечный процент рынка мобильной техники, несравнимо более высокий порог входа для разработчика, стоимость самой разработки и нулевой интерес аппартных производителей к их платформе. Swift — это вынужденный шаг по популяризации свой платформы при сохранении закнутого статус-кво. Насколько удачный сказать сложно, но без него апле бы попросту захирел и в мобильной области, как уже случилось с настольной.
Описание в обратной нотации, т.е. "имя-тип" диктуется не огладкой на Pascal или тенденциями, а простым требованием синтаксиса там, где описние типа опционально. В противном случае текст программы читается (и возможно компилируется) неоднозначно.
Фигурные же скобки — это просто всего один из трех возможных на клавиатуре вариантов самой краткой записи начала и конца. Квадратные как-то "сроднились" с индексацией, вот и получается что выбрать производителю просто не из чего. Кому хочется больше альтернативщины, те используют круглые, кому что попроще — фигурные :)
Для андроида нет никакой разницы в используемом языке, лишь бы он мог вызывать Java, так что писать можно абсолютно на чем угодно, а уж на любых JVM языках и подавно.
Если говорить о языках JVM, то разница будет только в настройке процесса компилятции и рюшках, доступных в среде.
Kotlin в обоих случаях не доставляет абсолютно никаких проблем, но как дела обстоят у других я не интересовался, возможно тоже без проблем.
Насчет смены жавы — я просто не верю.
Причина проста: никто не будет переписывать существующий код. Во-первых, потому что в принципе не будут (текущее лоскутное одеяло АПИ тому подтверждение) и, во-вторых, потому что без баквард-компатибилити гугл потеряет огромное количество "лайков". Поддержать же два языка бессмысленно. Поэтому я думаю, что Java в андроиде навечно.
Насчет крупных проектов — это философский вопрос, на самом деле.
К примеру я, не так уж и давно, перестал писать вполне себе крупный проект на языке С, который собирался таким зверем как Watcom 8.0, про который многие уже и не знают, наверное.
На работе народ вполне себе непрерывно пишет на Borland C 3.0.
Собственно, в самой старости языка нет никакой проблемы с точки зрения поддержки проекта, если функционал этого проекта состоялся.
Если рассуждать в принципе, то таких преимуществ одно - это возможность использовать АПИ напрямую, без его заново. Это касается как самого виндового АПИ, так львиной доли сторонних библиотек, т.к. процент чего-то стоящего написанного на паскале, в сравнении с С - незначителен.
Если же рассматривать только создание приложений, где полностью хватает функционала VCL, то преимуществ я не вижу. Только архитектурные, связанные с различиями языков в принципе.
Это два разных языка. Рассматривать переход с одного на другой разумно только если один из них предоставляет какие-то средства, вообще не реализуемые в другом.
К примеру, в свое время одним из критериев перехода на С для меня стала практически полная невозможность в паскале использовать ни ассемблер, ни код из С. Т.е. в те времена, если под что-то не было TPU (то что в дельфи DCU), то ты не можешь это реализовать практически никак. А в те времена как раз играли в видео с прямым доступом к памяти, перекодировали тектовый кодогенератор, чтобы сделать "графическую мышь в тексте", пимали резидентов и прочее.
Сейчас возможность средств различается не принципиально. Да и язык этот мне уже не нравится. Меня бесит подход "один класс - один файл". С ужасом смотрю на компоненты дельфи, пипа инспектора объектов, котрые занмают мегабайт одним файлом. Я так думать уже разучился :)
Правильно помнишь. Еще оба эти компилера были первыми, котрые имели серьезную, шокирующую по тем временам, оптимизацию кода.
Семантик запомнился еще тем, что имел уникальные библиотеки, для той же графики, математики и писания резидентов, когда ризидентом висело только ядро, а вункционал подгружался при импользовании.
Можете привести определение безопасности, которому соответствует эта ошибка и пример кода, в котором она является небезопасной?
Приведенный у вас код не имеет отношения к обсуждаемому.
Второй вопрос: какой процент "ложных срабатываний" ошибки приемлем для комфортной работы?
Т.е. в каком проценте случаев возникновения этой ошибки код, на котором она возникла, не будет иметь никакого отношения от той "опасности" от которой она защищает.
Эти "пара кликов" займут 0.0001% времени в задаче "понять куда, как и когда их надо воткнуть".
Я подозреваю, что задачами по адаптации чужого кода, написано непойми как хз сколько лет назад, без коментариев и, возможно, даже без исходников Вы если и занимались, то не часто.
Просто поверьте, что тупое втыкание аннотаций к чужому коду может привести к проблемам по крайней мере не менее сложным чем "дебажить нпе в продакшине"
Да, аналогично, но в андроиде ее практически нет.
Во-первых, у котлина есть автоматическое создание доступа к элементам описанным в лайауте (т.е. создавать переменные в классе вообще не нужно).
Во-вторых, в андроиде есть дизайнер.
В свифте дизайнер(ы) напоминают "жалкое подобие левой руки" и, как правило, весь инерфейс создается в рантайме полностью вручную.
В-третих, из-за наличия дизайнера, в коде под андроид вы оперируете УЖЕ созданным интерфейсом и, соответственно, в активити\фрейме… можно использовать любой способ доступа к элементам (в том числе вручную lazy, если вас устраивает безумный оверхед на классах для каждой анонимной функции). При ручном создании интерфейса этим "лейзам" просто неоткуда брать компонент, поэтому используются всякие аналоги вида "firstAssign", но их не всегда удобно использовать.
Поняли правильно, но я там дальше написал использование.
Это не то.
Это глобальный ключ.
Я не хочу отключать проверки во всем проекте, без возможности указать его действие для модуля он для меня бесполезен.
Можно указать раздельные ключи индивидуально для каждого файла в IntelliJ?
Он убирает оверхед проверок, а мне нужно другое: а) отключить исключение из smart-cast для var и б) временно выключить ошибки преобразования, т.е. временно интерпретировать типы не как "?", а как "!", что позволит мне оперировать nullable без огорода "!!" в коде.
Получается, что то что я написал выше: java-языкХ-java — это вполне правильно.
Языков JVM, которые бы не позволяли вызвать ява-код и быть вызванными из него не существует.
А то что типы могут потеряться и и тому подобное — это уже не принципиальные особенности т.к. они логически обоснованы разными языками.
Ясно.
Ты серьезно считаешь, что работу с миллионом существующих библиотек Java я долен начинать с их реверс-инжиниринга в попытках понять как они работают и чем чревато их использование с последующей их модификацией наружними аннотациями?
Ты сам-то так пробовл делать?
Сколько времени остается на ту работу за которую платят зарплату?
Чегож вы все читаете не то что написано, а то, на что знаете ответ?...
Где написано что нулевые типы в котлин — это плохо?
Где написано что я не понимаю откуда берется null?
Претензии к текущей реализации 2:
Ошибка компиляции, исключение из случаев safe-check, фактическая польза от которой, на практике, составляет мизерную часть тех мест в которых ее выбразывает компилятор, а во всех остальных она вызывает только раздражение.
А далее можете цитировать себя сами со всем обилием возможных проблем.
Вот пример именно Ваших слов с последствиями.
В текущей архитектуре код хлопнется на проверке парамеров внутри "Dispatch" в РАНТАЙМЕ, т.е. все танцы с "?" и "!!", которые я вынужден использовать в исходниках, оказываются совершенно бессмысленными.
Это всего лишь кратенький пример иллюстрация.
Обойти в нем использование "!!" можно несколькими способами.
Но в реальной жизни, к сожалению, не все они удобны или применимы.
К примеру, при работе с интерфейсом swing в одной функции может происходить общение с кучей элементов интерфейса, каждый из которых nullable и с ним производится всего 1-2 действия.
Ни оборачивать каждый элемент в лямбду, ни заводить локальную переменную для них не имеет никакого смысла — это просто хуже читаетя и занимает больше места.
Приходится городить кучи "!!" в местах, которые гарантированно не null при использовании.
Это достает, вплоть до написание глобальной аннотации к классу.
Огромное спасибо за отклик.
Рад что одиозное название не отпугнуло от чтения
В данном случае, как в аббревиатуре RTFM, ругательная часть просто является обозначением, а не моим отношением :)
К сожалению, мой английский заточен на общение и кино, а написание довольно абстракных технических вопросов и пояснений мало того что отнимает огромное количество времени, так еще и, скорее всего, вызывает недоумение, поэтому многие вещи, которые хотелось бы иметь или о которых хотелось бы спросить я уточнить на форумах Kotlin не могу.
Пользуясь случаем хотелось бы обратить внимание на такие возможности:
В результате этих двух пунктов можно было бы вынести какой-то код в отдельное место и указать для него другие правила (например отключить тот же null-safety, который при работе с каким-нить свингом просто мозг выносит т.к. превращает исходник в забор из "!").
Во!
В Kotlin точно так же.
Я пытался написать плагин к JavaDOC и вызвать явовский парсер из Kotlin не смог вообще. Именно из-за обилия перегруженных функций с одинаковыми типами параметров (куча форм вызова main с передачей ей строковых параметров).
Это только слова, к тому же без уточнения "non-private" еще и неправильные (и это без учета JvmField).
Во всех случаях кроме наличия обоих get\set в классе будет поле.
Я не помню, но вроде и с protected-ом будет protected поле, которое будет использоваться напрямую в родном классе и наследниках.
Еще раз: зачем приводить бесполезные ссылки?
Поверьте, я читал 99% документации, благо ее не вагон.
Фактическое поведение компилятора сложнее 3х строчек описания
Мы же вроде про мобилки, а там iOS. МacOS это "гуй на линуксе" или я все перепутал?
Впрочем, бог с ними.
Любые рассуждения на тему могут\будут\почему все равно голимые домыслы, которые еще и к теме статьи отношения не имеют :)
Т.е. существуют языки, в которых невозможно устаномить listener для класса на Java?
Если это так, то спасибо, не догадывался.
А какая ниша применения у такого рода языков?
В ссылках на то, что не имеет отношения к тексту есть какой-то смысл?
Какой?
Я цейлон не изучал, но на их сайте указан таргет JVM и в описательной части приведены примеры для использвания с Java EE. Прямые их примеры использования жавы тут:
https://github.com/ceylon/ceylon-examples-jdk
Как это может работать без совместимости с Java?
Любой JVM язык полностью совместим с жавой. По определению :)
Вообще, ассемблер JVM крайне примитивен и, если бы в него, в свое время, конструктивно не были бы воткнуты всякие "хаки" для ускорения, то для него можно было бы собрать вобще любой язык, с любыми произвольными возможностями. Т.к. основной задачей любого JVM языка является совсем не поддержка этого ассемблера, а обеспечение точного и однозначного вызова java-языкХ-java, то все они абсолютно одинаково с ней "совместимы": генерируют точно такие же классы, неотличимые в среде выполнения от сгенерированных жавой.
С "доложить рантайм" понятно, но стимула делать это у гугла я пока не вижу. С апле ситуация другая совсем. У них крошечный процент рынка мобильной техники, несравнимо более высокий порог входа для разработчика, стоимость самой разработки и нулевой интерес аппартных производителей к их платформе. Swift — это вынужденный шаг по популяризации свой платформы при сохранении закнутого статус-кво. Насколько удачный сказать сложно, но без него апле бы попросту захирел и в мобильной области, как уже случилось с настольной.
Описание в обратной нотации, т.е. "имя-тип" диктуется не огладкой на Pascal или тенденциями, а простым требованием синтаксиса там, где описние типа опционально. В противном случае текст программы читается (и возможно компилируется) неоднозначно.
Фигурные же скобки — это просто всего один из трех возможных на клавиатуре вариантов самой краткой записи начала и конца. Квадратные как-то "сроднились" с индексацией, вот и получается что выбрать производителю просто не из чего. Кому хочется больше альтернативщины, те используют круглые, кому что попроще — фигурные :)
Для андроида нет никакой разницы в используемом языке, лишь бы он мог вызывать Java, так что писать можно абсолютно на чем угодно, а уж на любых JVM языках и подавно.
Если говорить о языках JVM, то разница будет только в настройке процесса компилятции и рюшках, доступных в среде.
Kotlin в обоих случаях не доставляет абсолютно никаких проблем, но как дела обстоят у других я не интересовался, возможно тоже без проблем.
Насчет смены жавы — я просто не верю.
Причина проста: никто не будет переписывать существующий код. Во-первых, потому что в принципе не будут (текущее лоскутное одеяло АПИ тому подтверждение) и, во-вторых, потому что без баквард-компатибилити гугл потеряет огромное количество "лайков". Поддержать же два языка бессмысленно. Поэтому я думаю, что Java в андроиде навечно.
Насчет крупных проектов — это философский вопрос, на самом деле.
К примеру я, не так уж и давно, перестал писать вполне себе крупный проект на языке С, который собирался таким зверем как Watcom 8.0, про который многие уже и не знают, наверное.
На работе народ вполне себе непрерывно пишет на Borland C 3.0.
Собственно, в самой старости языка нет никакой проблемы с точки зрения поддержки проекта, если функционал этого проекта состоялся.