> Дмитрий Белькевич ©   (14.04.17 16:04) [319]
>
> > Тут надо понять что конкретно мы обсуждаем.
>
> 1. Если стартап 'пошёл', то можно и заплатить. А если не
> идёт - то никакие бесплатные средства не помогут.

"Пошел" он или нет, ты узнаешь только после релиза. Еще не факт, что после первого. Эти потраченные деньги тебе никто не вернет.

> 3. Толкового программиста найти вообще проблема. Если же
> он толковый на тех же плюсах, то переучится можно достаточно
> быстро.

А ему оно надо? Совсем не тот случай, когда можно поиграться с чем-то новым ради строчки в резюме.

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

Тут просто надо быть честным и признать, что в такой ситуации либо берут один из многочисленных бесплатных вариантов, либо делфи со всеми ее сторонними платными библиотеками с торрентов.

Понятно, что есть страны где программист со своей $10 тыс в месяц на основной работе для стартапа может себе позволить выбирать между С++, Java, C# и Delphi. Но в России это обычно выбор между C++, Java, C# и торрентами.

> Если же он толковый на тех же плюсах, то переучится можно
> достаточно быстро.


Спорный вопрос. Я не наблюдал такого процесса.

> kilkennycat ©   (14.04.17 15:28) [318]


> сишарп полностью удовлетворяет.

главный недостаток C# это .NET, как это ни странно звучит.

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

А если стартап легко поместится в веб, то Delphi процентов на 99,99 вообще не будет учавствовать как вариант.
(мои 5 коп.)

>>Kerk ©   (14.04.17 14:51) [317]
 Если не будет сочтено за оффтопик, хотелось бы понять, что такого прорывного случилось за последние 20 лет в технике программирования, ради чего стоило бы "выглядывать из окна"? Я вот кроме web-технологий и модной последнее время кроссплатформенности ничего не заметил, кроме рюшечек. Те же дженереки я использовал в C++ еще в 98-ом, если мне память не изменяет, как раз скоро 20 лет будет. Понимаю, что это не совсем те же дженерики, но не суть. Странный пример, просто.

> ухты ©   (14.04.17 17:15) [324]

Конечно.

> Внук ©   (14.04.17 17:15) [325]
>
> Я вот кроме web-технологий и модной последнее время кроссплатформенности
> ничего не заметил, кроме рюшечек.

А этого мало? Nosql, облака, бигдата всякая. Не, понятно, что все это было еще при наших дедушках, но в мейнстрим пришло лишь недавно.

> Те же дженереки я использовал в C++ еще в 98-ом, если мне
> память не изменяет, как раз скоро 20 лет будет. Понимаю,
>  что это не совсем те же дженерики, но не суть. Странный
> пример, просто.

Пример как раз хорош тем, что он очень показателен. Впервые дженерики появились чуть ли не в 60е, но так как в паскале и Delphi их долго не было их и не заметили. До сих пор много Delphi-программистов считают дженерики да лямбды не полезными частями языка, а рюшечками ненужными.

Не мало. Просто это вещи, которые не всем нужны.

> А ему оно надо?


Оно компании надо.


> Я не наблюдал такого процесса.


Я видел несколько раз.


> главный недостаток C# это .NET


Согласен.


> Но в России это обычно выбор между C++, Java, C# и торрентами


Лазаря можно еще вспомнить. Местами мне нравится больше Делфи. Вполне годная и бесплатная среда. Главный минус - отладтик на троечку. Можно в связке со стартером использовать. Я так у себя делал, основная отладка - винда, делфи, специфичиские вещи на линуксе, на лазаре. На одном коде, с минимумом телодвижений.


> Nosql, облака, бигдата всякая.


Частично в делфи уже есть, частично покрывается компонентами. Но и двигаться Эмбе/Идере есть еще куда, пусть работают.

Внук ©   (14.04.17 18:37) [327]


> Просто это вещи, которые не всем нужны.


Это да. Я лично не могу себе представить, где в повседневной жизни мне нужны дженерики. Понятно, что во всяких библиотечных классах они удобны, но многие ли из нас разрабатывают библиотечные классы, кроме тех, которые уже разработаны, и так ли они нужны... ?

Кроме всего прочего, в ногу себе ими выстрелить или написать монстрообразный код, увы, несложно, благо таких примеров достаточно.

Дмитрий Белькевич ©   (14.04.17 19:55) [328]


> Я видел несколько раз.


Даже у нас с тобой разный опыт, боюсь, что твое обобщение преждевременно. Нет, я не спорю, можно переучиться с С++ на Паскаль (и наоборот), но это небыстро, чтобы начать думать на Паскале должно пройти сколько-то времени.

> Дмитрий Белькевич ©   (14.04.17 19:55) [328]
>
> > А ему оно надо?
>
> Оно компании надо.

Компании надо доступ к квалифицированному рынку труда. Брать С++ников, чтоб они писали на делфи конечно можно. Но хотелось бы без этого :)

> > Nosql, облака, бигдата всякая.
> Частично в делфи уже есть, частично покрывается компонентами.
>  Но и двигаться Эмбе/Идере есть еще куда, пусть работают.

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


> Игорь Шевченко ©   (14.04.17 20:25) [329]
> Это да. Я лично не могу себе представить, где в повседневной
> жизни мне нужны дженерики. Понятно, что во всяких библиотечных
> классах они удобны, но многие ли из нас разрабатывают библиотечные
> классы, кроме тех, которые уже разработаны, и так ли они
> нужны... ?

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

а что значит библиотечные?
вот у нас во вполне себе не библиотечном проекте есть много всяких мест где применили дженерики,
например клиенту в работе надо часто делать запросы на нттп сервер, ну вот все запросы сделали "хоть и безобразно зато единообразно" )), т.е. через дженерики.
типа httphelper.get<T>, httphelper.getasync<T>, httphelper.post<T>, httphelper.postasync<T>, ну просто чтобы было хорошо ) и никаких библиотек

> Kerk ©   (14.04.17 21:02) [330]

В самом деле, зачем,
если время написания узкоспециализированных классов под конкретный проект с нуля вряд ли составляет более 5% от всего проекта?
Причем это время не зависит от использования (не использования) дженериков.

> Но хотелось бы без этого :)


Кто бы спорил, хочется быть богатым и здоровым. И, желательно, бесплатно :)

Дженерики у нас не более чем сахар, исключительно в разных TList'ах. Удобно, меньше захламляет код. Но сказать, что бы они были критичными - то нет.
Лямбды, скорее, критичны. Есть мест штук 20 распараллеливания кода, удобно лямбдами делать.
А из-за отсутствия reference to procedure в лазаре пришлось довольно много всего переписывать - контексты передавать.

> ухты ©   (14.04.17 21:10) [331]

Жизненный и понятный пример.

---

Простой и гибкий инструмент, позволяющий обобщить код и усилить статическую типизацию одновременно. Не, не нужен. Там, где раньше жонглировали указателями и напрямую приводили типы, теперь все строго проверяет компилятор. Да зачем нам эти глупости? Это этот, как его - creeping featurism :)

Kerk ©   (14.04.17 21:02) [330]


> "не представляю зачем нужен полиморфизм тем, кто не пишет
> библиотечные классы"


Полиморфизм полиморфизму рознь. Дженерики позволяют выполнить идентичные действия над разными типами данных, полиморфизм в ООП позволяет использовать  интерфейс объекта, не зная о его структуре.
Мне за длинную программистскую жизнь второе приходилось использовать гораздо чаще, чем первое.

> Дженерики позволяют выполнить идентичные действия над разными
> типами данных


а без дженериков это никак?

> Игорь Шевченко ©   (14.04.17 23:17) [337]
>
> Полиморфизм полиморфизму рознь. Дженерики позволяют выполнить
> идентичные действия над разными типами данных, полиморфизм
> в ООП позволяет использовать  интерфейс объекта, не зная
> о его структуре.

Не, Игорь, ты сказал одно и то же разными словами :)

Полиморфизм в ООП точно так же позволяет выполнить идентичные действия над разными типами данных. Как в том хрестоматийном примере, где ты вызываешь метод Draw, не зная с каким конкретно классом имеешь дело - квадратом или кругом.

Понятно, что есть в этой логике и существенные различия. Но иначе это был бы один тип полиморфизма, а не два :)

> Мне за длинную программистскую жизнь второе приходилось
> использовать гораздо чаще, чем первое.

Мне тоже, чего уж там.