Delphi vs C#

Всем привет.
Я уже давно люблю покодить на делфи(7) и вот решил попробовать на с#.
Тема глупая и затасканная, но все же какие преимущества я получу(и недостатки) с точки зрения любителя.

0

Сообщение от korvin_ достаточно нормальный UI на Delphi/InterfaceBuilder/SceneBuilder/whatever-UI-tool

а потом меняешь масштабирование шрифтов, размер экрана и создаешь локализацию и пытаешься хоть чтото разглядеть на этом "нормальном UI". единственные кто более менее решил эти проблемы это хтмл+css и в какойто мере андроид (но там своя наркомания).

1

Сообщение от Shamil1 А свойства задать?

Самое главное свойство - датабайндинг - я и забыл .

Добавлено через 6 минут

Сообщение от pycture а потом меняешь масштабирование шрифтов, размер экрана и создаешь локализацию и пытаешься хоть чтото разглядеть на этом "нормальном UI". единственные кто более менее решил эти проблемы это хтмл+css и в какойто мере андроид (но там своя наркомания).

При этом локализация может быть и RTL (right-to-left). Плюс скринридеры должны нормально форму читать.

0

Сообщение от korvin_ Есть чему, вообще-то.

хтмл код задаёт иерархию объектов (раскладку) и разъезжаться там особо нечему. За внешний вид отвечает цсс.

А что будет если в классе bbcode_quote увеличить margin-left c 10px до 100px? Можем легко проверить:

Миниатюры

   

0

Сообщение от Shamil1 А свойства задать? Идентификатор Имя ресурсного файла и ключ в нём для метки. Задать валидацию (или несколько). Имя ресурсного файла и ключ в нём для сообщения об ошибке валидации (или несколько). Возможно, задать для контрола источник данных. Возможно, задать обработчики для каких-то событий. Плюс внешний вид.

Т.е. в XAML всего этого делать не нужно?

Добавлено через 1 минуту

Сообщение от Shamil1 хтмл код задаёт иерархию объектов (раскладку) и разъезжаться там особо нечему

Ещё как есть чему.

Сообщение от Shamil1 За внешний вид отвечает цсс.

Ага, и там можно всю эту иерархию и перефигачить так, что не узнать потом будет.

Добавлено через 3 минуты

Сообщение от pycture а потом меняешь масштабирование шрифтов, размер экрана и создаешь локализацию и пытаешься хоть чтото разглядеть на этом "нормальном UI". единственные кто более менее решил эти проблемы это хтмл+css

Ага. «более менее» тут как раз уместно. Между тем, нативный UI macOS нормально выглядит при масштабировании.

1

Сообщение от korvin_ Т.е. в XAML всего этого делать не нужно?

Нужно. Поэтому XAML два экрана занимает, а не пару строк.

0

Сообщение от Shamil1 Вместо того, чтобы вручную поместить на форму редактирования сипульки два текстбокса, а на форму редактирования кудрёнка чекбокс и дропбокс

Интересно, как более чем полная разница в контролах форм соответствует Вашим предыдущим условиям

Сообщение от Shamil1 Предположим, у меня есть две экранные формы. Одна для редактирования сипулек, другая для редактирования кудрёнков. Формы похожие.

?
Нулевое пересечение по набору контролов - это похожие формы, да?
(кнопки ОК+Отмена тут из рассмотрения исключаем).

Плюс, Вы забыли и другие заданные Вами рамки - а именно:

Сообщение от Shamil1 Если исходный код пишет программист, то можно получить одну из другой контекстной заменой "сипулька" на "кудрёнок" (плюс, возможно, ещё несколько незначительных изменений).

т.е. разницу форм Вы предполагали преимущественно в лейблах/заголовках или в текстовом содержании дропбоксов/листбоксов, но НЕ в реальной замене одних контролов на другие. Раз контекстная замена.

Соответственно, Ваши возражения исходя из совершенно новых условий - не принимаются!

0

Сообщение от VTsaregorodtsev Нулевое пересечение по набору контролов - это похожие формы, да?

Почему нулевое? Вы мысленно представьте себе форму для редактирования сипулек и форму для редактирования кудрёнков. Они очень похожие. Формы занимают по полэкрана, а отличаются двумя небольшими прямоугольниками.
При этом хамл или хтмл код форм - это целый экран текста, в котором различаются всего две строки.

Сообщение от VTsaregorodtsev но НЕ в реальной замене одних контролов на другие.

Почему? Заменить один контрол на другой - это заменить в коде одно слово (тип контрола).

0

Сообщение от Curry Да, если не можем как в Делфи, то объявим это фичей. Я уже писал - срок действия патентов на дельфовый вариант разработки должен уже подходить к концу (1995 + 25), и скоро появится совсем новая студия в которой "раньше вам нужно было ручками в XAML, а теперь ляляля".

Что за ахинея? Кто что фигнёй обзывал? Какие патенты? Редактор WinForms эти патенты не помешали сделать "как в Дельфи", а в WPF помешали? Так трудно себе представить, что декларативный способ описания UI мог быть выбран осознанно как фича?

Сообщение от Curry Как сделать что бы в списке отображались дата последнего обновления пакета, статус разработки (бетта, релиз-кандидат), тип лицензии, платность/шарварность (а то и цена)? Как сортировать пакеты по датам обновления, статусу разработки, количеству скачиваний и т.д.? Он может искать не только по названиям пакетов, а проиндескировать документирующие комментарии в коде (или представленную документацию)? Я набрал AES и получил хлам. Гугл объяснил что сишарпники пользуются BouncyCastle. На сайте BouncyCastle нормальной документации нет, хотя по нугету скачиваний много. Можно только нагуглить как экспериментаторы добились работающего кода. В самой msdn, кстати, тоже не вдруг найдёшь, что можно, оказывается, aes/cbc с помощью System.Security.Cryptography. Хотя на это мне нугет должен был бы указать когда я про AES спрашивал.

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

Собственно, помойкой репозиторий станет, если на него навесить всё вышеперечисленное.

Сообщение от Curry Может и контекстные подсказки в редакторе убрать - я же должен всё знать и помнить? Может что то из моих (вполне естественных и реализованных в других местах) хотелок есть не в комьюнинти, а платной версии VS?

Контекстные подсказки не тоже самое, что полная документация. Не надо это сюда приплетать. У репозитория пакетов есть чёткое предназчение - хранилище пакетов. Вы уже должны знать, что вы там ищите и как этим пользоваться. Это не магазин, где товар со всех сторон расписывается.

Сообщение от Curry А почему бы даже и не красивый магазин?

Потому, что это склад.

0

Сообщение от Usaga Кто что фигнёй обзывал?

А кто что фигнёй обзывал?

Сообщение от Usaga Редактор WinForms эти патенты не помешали сделать "как в Дельфи"

Если бы как в Delphi.

Сообщение от Usaga Так трудно себе представить, что декларативный способ описания UI мог быть выбран осознанно как фича?

Не трудно. Только к нему нужно ещё и удобное средство графического построения.
Shamil1 тут привёл аргумент что дело в скорости формошлёпства. Не могу сказать что быстрее для скоростного формошлёпства - текст набивать или мышью таскать. Мне вообще жалко тех фомрошлёперов у которых план 50 форм в час, хотя и допускаю что IT индустрия может этого требовать. По счастью, можно специализироваться в другой области. Если я и делаю формы, то не по жёстко заданному рисунку, а по достаточно мягкому (в этом смысле) ТЗ, и я могу разместить компоненты так и эдак посмотреть что больше нравится, подвигать контролы. В итоге лучше получится, да и смена деятельности полезна согласно НОТ. Большую часть времени и так код набираю.

Сообщение от Usaga Это всё вообще к репозиторию не относится. Вы или знаете какой именно пакет вам нужен и как им пользоваться или не знаете и лезете за этим в гугл.

Это всё равно что сказать про окно редактирования кода куда бы предложили вставить всякие автодополнения и контекстные подсказки "Это вообще к редактору не относится. Вы или знаете какой именно метод вам нужен и как им пользоваться или не знаете и лезете за этим в гугл.". Оправдываете очевидные недоделки.

0

Сообщение от Curry А кто что фигнёй обзывал?

Речь о этой фразе:

Сообщение от Curry Да, если не можем как в Делфи, то объявим это фичей.

Я последнее слово не так прочитал. Но с каких пор другой подход сразу становится "не можем как в Дельфе"?

Сообщение от Curry Не трудно. Только к нему нужно ещё и удобное средство графического построения.

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

Сообщение от Curry Это всё равно что сказать про окно редактирования кода куда бы предложили вставить всякие автодополнения и контекстные подсказки "Это вообще к редактору не относится. Вы или знаете какой именно метод вам нужен и как им пользоваться или не знаете и лезете за этим в гугл.". Оправдываете очевидные недоделки.

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

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

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

0

Сообщение от Usaga Удобное средство графического построения сильно противоречит идее декларативного подхода.

Это и есть декларативный подход. Не процедурный же.

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

Опять "лезете в гугл". Может быть утилита командной строки для подкачки пакетов, пусть себе. Но если мы работаем в IDE, то IDE могло бы предоставлять максимум полезной информации вокруг пакетов. Странно как то спорить на тему "должно ли быть удобно".

Сообщение от Usaga Это не магазин и не каталог.

Это должен быть удобный каталог. А коли там есть и платные пакеты, то и магазин заодно. MS не может себе позволить сделать как на sourceforge или яндексмаркете ? Прямо внутри IDE?
Какой ни будь микрочип в своём средстве разработки для 8мибитных (в том числе) микроконтроллеров себе это может позволить, а MS нет? Странно.

0

Сообщение от Curry Но если мы работаем в IDE, то IDE могло бы предоставлять максимум полезной информации вокруг пакетов.

В IDE есть менеджер NuGet пакетов. Он предоставляет возможность поиска. Поиск ничем не отличается от поиска, например, в AppStore. Кроме того, менеджер сообщает о новых версиях уже установленных пакетов. Я не представляю, какую ещё функциональность можно добавить к уже имеющейся.
Также есть возможность искать на разных NuGet серверах. Когда разрабатываешь сложную систему, удобно зависимости между подсистемами оформлять в виде NuGet пакетов. Поднимаешь свой NuGet сервер. В сборку проектов добавляешь шаги по подготовке и публикации (на своём сервере) NuGet пакетов. В проекте, который эти пакеты использует, можно нажатием одной кнопки обновить во всех проектах решения все установленные пакеты с выбранного сервера до последней версии (либо обновлять каждый пакет отдельно, задавая версию, до которой нужно обновить этот пакет).

0

Сообщение от Shamil1 В IDE есть менеджер NuGet пакетов. Он предоставляет возможность поиска.

просто поиск по словам входящим в названия пакетов.

Сообщение от Shamil1 Я не представляю, какую ещё функциональность можно добавить к уже имеющейся.

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

0

Сообщение от Curry Это и есть декларативный подход. Не процедурный же.

Это визуальный дизайнер. Декларативный - описание на специальном языке, специально для этого рождённом.

Сообщение от Curry Опять "лезете в гугл". Может быть утилита командной строки для подкачки пакетов, пусть себе. Но если мы работаем в IDE, то IDE могло бы предоставлять максимум полезной информации вокруг пакетов. Странно как то спорить на тему "должно ли быть удобно".

Ничего IDE не должна вам про пакеты предоставлять кроме того, что уже есть. Ещё раз: вы путаете магазин с простым хранилищем. Оттуда и недовольства.

Сообщение от Curry Это должен быть удобный каталог. А коли там есть и платные пакеты, то и магазин заодно. MS не может себе позволить сделать как на sourceforge или яндексмаркете ? Прямо внутри IDE?

Это не должен быть удобный каталог. Это просто репозиторий для размещения библиотек имена которых и назначения вы уже знаете заранее. Чтобы не качать архивы с этими библиотеками со всего интернета и руками их в reference не подключать. Оно не задумывалось как каталог или магазин. Если вы не знаете, что за пакет вы видите, то он вам не нужен. Если вам нужна какая-то фича, то вы её ищете в сети, где и примеры и документация. А потом по названию тащите пакет из репозитория.

Не надо пытаться использовать вещь не по назначению и жаловаться, что он неудобна для этого.

Сообщение от Curry просто поиск по словам входящим в названия пакетов.

Сообщение от Curry А я хочу указать фильтры: показывать только пакеты обновлявшиеся последний раз не ранее трёх месяцев, имеющие статус разработки релиз-кандидат и выше, бесплатные, с оценками пользователей не менее ..., с количеством оценок не менее ..., имеющие в описании пакета такие то слова или такие то слова.

Это всё бесполезные вещи. Вы должны заранее знать имя пакета и как им пользоваться. Если вы это знаете, то эти фильтры не имеют никакого смысла.

0

Сообщение от Usaga Это визуальный дизайнер. Декларативный - описание на специальном языке, специально для этого рождённом.

Декларативный подход, это "что делать". А уж как это задаётся, в визуальном дизайнере, на специальном языке, или не специальном, это уж как сделать.

Про остальное: вы повторяетесь. Я свою позицию высказал. Распевать на два голоса докучную сказку мне не интересно.

Про бесполезность GC.
Посмотрим на код сгенерированный по шаблону простого проекта WinForms. Там увидим
Если бы в .NET Существовал автовызов деструкторов, то была бы только строка описания components (с типом класса а не интерфейса). Dispose бы не было и его логика была бы один раз реализована при описании базового контейнера.

То есть, написать то что угодно на языках с GC можно, но кода больше.
С другой стороны, в плюсах реализовать это "что угодно" тоже можно, но применяя смартпоинтеры. Но беда плюсовых программ в том что компилятор не может заставить их применять и применять правильно. Плюс злоупотребление адресной арифметикой. Вот они и текут. Это понимали создатели rust-а, я ожидал его взлёт через несколько лет. Увы, не вышло.
Но, думаю, в этом направлении (избавления от GC) умные головы работают.
Ещё признак неуспешности GC - практическое отсутствие до сих пор его аппаратной поддержки. То что действительно было востребовано - плавающая точка, обработка изображений, страничная подкачка - всё получило аппаратную поддержку.
А про аппаратную поддержку GC говорят с момента его появления. Особенно после появления java. Но есть только частичные решения отдельных фирм, насколько понимаю, ни разу не распространённые.

То что сейчас мы вынуждены использовать GC не означает что так всегда и будет. В IT индустрии бывают резкие зигзаги. Это не значит что все начнут писать на плюсах. Будет что то другое.

0

Сообщение от Curry Про остальное: вы повторяетесь. Я свою позицию высказал.

И я вам указал, что эта позиция основана на неверном представлении о предмете.

Сообщение от Curry То есть, написать то что угодно на языках с GC можно, но кода больше.

Наоборот. Аналог такого фрагмента вы бы один чёрт писали на плюсах. Плюс смартпоинтеры по всему коду. Плюс полное отсутствие рефлексии, которая ну очень широко используется как раз для того, чтобы кода было меньше.

Аппаратный GC? Может и WinForms силами GPU? И я не про рендеринг. Есть же предел всему, что можно в железо засунуть. Разве это показатель неуспешности чего-то?

Сообщение от Curry То что сейчас мы вынуждены использовать GC не означает что так всегда и будет.

Нет, не вынуждены. С++ никуда не делся. Дельфи никуда не делась, хоть и сдала позиции (скорее всего из-за ценовой политики).

0

Сообщение от Usaga Аналог такого фрагмента вы бы один чёрт писали на плюсах.

Нет. Его не было бы. Автовызов деструторов рулит.

Сообщение от Usaga Плюс полное отсутствие рефлексии

Какое это имеет отношение к GC ?
Это отдельная тема. Рефлексия в Delphi, внезапно, есть. В compiletime. Этого достаточно для VCL.

Сообщение от Usaga Есть же предел всему, что можно в железо засунуть. Разве это показатель неуспешности чего-то?

Если нечто используется часто но не реализуется аппаратно, о это показатель неперсективности.
Отдельные библиотеки не реализуют аппаратно, т.к. у них множество альтернатив. Предела тому что можно реализовать аппаратно практически нет. То что реализовано аппаратно в грфкартах намного превосходит по сложности GC, но оно востребовано.

0

Да бросьте вы спорить, давайте лучше Аду изучать )

0

Сообщение от WH Да бросьте вы спорить, давайте лучше Аду изучать )

Я изучал. Хотел как то в новом проекте уговорить электронщиков применить более навороченный микроконтроллер в который Ада лезла, а то С надоело. Не уговорил. А для win или linux её применять смысла нет.

0

Почему Вы так считаете? (про Аду)

0