Да после др пришлось много страниц читать)

Мой первый ЯП был именно delphi, который наверно только ленивый не осилит.
Первое впечатление было на столько большим, что побоюсь обидить людей которые пишут на плюсах.
Сейчас я забыл уже много чего что знал, что без документации и не вспомню.
Многие компоненты которые, есть в Delphi очень не хватает на C# например VirtualTreeView
После Delphi я подсел на GameMerker6-7 Даже 3d игру сделал с редактором уровнем, уже не помню где исходники.

Не так давно мне нужно было для своих нужд написать программу из набора был только VS и списка того что там было, я более менее знал когда то VB.
Но выбрал C# наслышан о быстром освоении, хватило прочитать базового документа Program Files (x86)\Microsoft Visual Studio 11.0\VC#\Specifications\1033\CSharp Language Specification.docx и сделать задуманное.

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

Каждому человеку свой инструмент и пациент delphi будет очень очень долго еще будет жить.

Даже больше чем к Delphi? Не верю   


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


Вот слова одного заказчика. Не дословно  
- Лучше нанять неопытного недопрограммиста. Зато он сделает. Да, работает будет через пень-колоду. Со временем допилится напильником и будет работать вполне сносно. А можно нанять умного программиста, который шибко-шибко умничает на совещании, вешает лапшу, умничает, пишет правильный код и т.д. В итоге проект либо работает ещё хуже, чем у недопрограммиста, либо приходится ждать в 3-4 раза дольше указанных сроков.

Говорил он это не раз. На собственном опыте. Да и у меня был такой опыт при поиске исполнителей.

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

На линке запросы на пару-тройку скринов не пишутся?

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

Я сам писал такую софтину мониторинга сетевой папки. У windows 7 есть ограничения на: copy %1 prn или copy %1 \\server\printer1
Работает уже года два на нескольких компьютерах. И придётся её использовать дальше. Я и забыл про неё. Не глючит.
Пусть там овнокод на коленке, но работает ведь без проблем. Что ещё заказчику нужно для полного счастья?

Препятствий для этого нет. Только мне не очень понятно зачем это делать. 

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

Ага, в свое время Пол Грэм с Коммон Лиспом всех обставил.

На всех заказчиков одного Грэма не хватит 

@diadiavova


На самом деле пять способов записи одного и того же -- это достаточно интересно весело. 


До меня наконец дошла аналогия.  Если расписать сложное выражение на LINQ в циклы (запись через Enumerable.OrderBy -- ни к селу, ни к городу), то получится пять уровней вложенных блоков, с кучей дополнительных переменных и ветвлений. Такой код в процедурном программировании традиционно "упрощается" разделением на отдельные функции и аналогичными рефакторингами. Если повезло, и выражение красиво записывается через LINQ, количество кода заметно сокращается.

Проблема в том, что в шарпе не все выражения красиво представимы в виде LINQ: если выражение не однострочное, то приходится писать и фигурные скобки, и отдельный return; множество методов доступно только в Rx/Ix. Да и насколько .ForEach() превосходит foreach in -- вопрос открытый. 


Можно писать лесенкой.  В меру читаемо. Правда при повторном использовании подвыражения всё равно придётся вводить переменные. Если в F# минимум пять способов "перенаправить" результат вычисления в разные стороны, то, наверное, это и решает эту проблему.

В итоге к чему приходим? ФП рулит в вычислениях, сложных запросах и т.п. Что в википедии сказано в первых строчках.  


А это уже из разряда begin/end vs. {} -- различие в вызове функции в пять символов не настолько решает.


Ты просто не умеешь приводить нормальные человеческие примеры, оперируешь абстракциями и вычисляешь разницу в 5 символов. Разумеется, с такими объяснениями невозможно увидеть достоинств. И, прошу обратить внимание, в отличие от дельфистов я не орал "это никому не нужно" или "это полный бред" -- я просто пытался выудить из тебя информацию.

@Sanchezzz


Вот что в WPF г#вно -- это контрол дерева. Авторов этой поделки нужно четвертовать и останки скормить крысам. Простить можно всё, даже XAML, но TreeView -- никогда.

Не, есть, конечно, нормальные сторонние контролы, но они сторонние. Для банальных вещей уходить на сторону -- это странно.

@Akella


Судя по тексту, программист нужен на проект ровно один. То есть сроки короткие, качество кода некритично. Разумеется, для мелких одноразовых проектов, которые не нужно поддерживать, дешёвый программист, пишущий г#внокод -- самое то.


Ты всё перепутал. Истории на хабре минимум две было.

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

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

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

Это сообщение отредактировал(а) Sanchezzz - 19.5.2013, 12:58

Ну еще бы, с эдаким-то монстром работать  

Не только. Блоки в принципе более сложны для восприятия, поэтому о них речь вообще не идет.

То есть раскидывается по разным местам, в то время, когда можно описать последовательность действий как она есть и в одном месте.


Не только, но разговор с этого и начался, я тебе сказал, что в F# есть много прикольных вещей, использовать которые очень заманчиво. Если говорить о ФП вообще, то в C# уже довольно много функциональных прибамбасов и язык от этого только выиграл. Но, к сожалению, некоторые вещи из ФП, если и приходят в такие языки, то они либо не очень удобны, либо к ним не могут приладить все то, с чем они обычно привыкли соседствовать в ФЯ. В результате, хоть язык от этого и выигрывает, но всех преимуществ от такого приобретения он все равно не получает.

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

Ну, кто знает какие примеры для тебя нормальные. Сначала я привел пример с линком, как мне показалось для дотнетчика этот пример должен быть вполне понятным. Ты мне на это ответил, что линк типа реализован в шарпе, так что и говорить не о чем. Тогда привел пример с элементарными математическими функциями, этот пример должен быть понятен любому, кто в школе не все уроки математики проспал, привел просто для того, чтобы показать, что в фя для реализации подобной логики не требуется специально реализованных методов-расширений как это было в случае с линком для шарпа и продемонстрировал, что все работает точно так же. Если эти примеры для тебя абстрактны, то какие для тебя конкретны? Что-нибудь из той области, в которой ты работаешь что ли?   Что до умения приводить человеческие примеры, то твой стиль изложения уж очень доходчивым тоже не назовешь  

Твоя аргументация против F# и в пользу C# как бы указывала на то, что в C# все идеально, а все что не как в C# - ересь и должно быть предано анафеме  

Да днище ваш Делфи! Верняк!   

Если говорить о дорогих спецах, то бывают те, кто делают самым быстрым из правильных способов, и те, кто делают сложно, т. к. по другому не умеют, и потому дорого. Да и сама IT область молодая, новых технологий много. Просто знание технологий и практический навык создания сложных систем, это вещи разные. А заказчик, как правило, некомпетентен. Даже если он компетентен в своей области, он некомпетентен в IT и впарить ему можно все, что угодно.



Что за разработчик? Фрилансер? Обычно с серьезным проектом работает контора, а там по определению есть непосредственный начальник над кодерами, который выдает задания, в том числе исходя из сложности.

Хотя 3,5кк тебе, 3.5кк мне, а за 3 кк пусть турки делают тоже бывает, но этим должна прокуратура заниматься.

@diadiavova


Такие, чтобы я воскликнул: "Чёрт побери, да в аналогичном коде на шарпе чёрт ногу сломит!" Или: "Чёрт побери, да ради этого мне на шарпе в 5 раз больше кода писать!" Или вообще: "Да у меня такого совсем нет!"

Примеры с C# vs. Delphi:

1. Есть поддержка динамического типа. Зачем? Чтобы вызывать метод не как (int)Engine.GetService<DynamicOperations>.InvokeMethod(calculator, "Sum", new object[] { 123, 456 }), а как calculator.Sum(123, 456). Здесь не только сокращение кода, здесь сокращение количества участвующих в коде сущностей: нет движка языка, нет его сервиса Operations, нет операции вызова методов, нет создания массива для передачи аргументов, поэтому голова не пухнет от количества сущностей. Сама запись естественна для языка: функция записана как функция, аргументы -- как аргументы, поэтому код читать гораздо легче.

2. Есть генераторы. Зачем? Чтобы не реализовывать отдельный класс, реализующий автомат, вместе со всеми состояниями и укуренной логикой, а просто написать for .. if .. yield return. В логике написания автомата очень просто ошибиться. Надо из раза в раз переписывать одно и то же. Надо рассматривать кучу состояний и разный порядок вызовов аргументов для разных случаев.

3. Есть 50 автоматических рефакторингов. Зачем? Чтобы из-за одного простого преобразования кода не бегать по всему проекту вручную и не изобретать регулярки для найти-заменить, у которых точность 50%. Часто будет проще не рефакторить вообще, чем менять что-то, а это приведёт к кривой архитектуре и будет расти снежным комом. И решарпер практически никогда не ломает код (если на изменяемых объектах не используются отражения и аналогичные средства -- и то он предложит подозрительные места, проанализировав строки, поэтому можно добить вручную). В регулярках по коду я не могу быть уверен никогда.

4. Есть поддержка десятков языков, в том числе скриптовых. Зачем? Чтобы код, написанный на другом языке, можно было использовать. Чтобы можно было использовать скриптовые вставки. А не переписывать с нуля код и не заниматься перекомпиляцией ради простого изменения (на стороне клиента даже). Здесь у дельфи даже аналога нет -- только какие-то поделки с изобретёнными языками.

Ничто из этого нельзя перекрыть словами: "Да какие-то жалкие пять символов экономятся". Везде -- пропасть.

Когда ты берёшь запрос LINQ на C# и переписываешь на F#, по сути ничего не изменяется. Незначительно меняется синтаксис (в твоём примере! допускаю, что есть сложные запросы). Когда ты берёшь две вложенные функции и переписываешь разными способами, тоже по сути ничего не изменяется. Выражение как было примитивным, так и остаётся (опять-таки, в твоём примере! я не вижу сложных формул, где разница заметна).

Это сообщение отредактировал(а) Athari - 19.5.2013, 14:32

На сколько порядков это увеличит эффективность Злохи Антари? 

Этого можно добиться и без динамических типов. Прикрепи к object расширение InvokeMethod, который будет получать имя метода и массив (params) аргументов. Это сделать очень просто и вызывай calculator.InvokeMethod("Sum", 1,2, 3). Что-то вроде этого.

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

Объяснение непонятно. Ты говоришь о том, что есть генераторы, а отвечая на вопрос "зачем?", пишешь, что для того, чтобы не писать их вручную, хотя логичнее было бы расписать для чего они нужны и на сколько порядков их использование увеличит эффективность Злохи.

В студии?  

С каких пор этот платный инструмент стал частью языка или среды разработки? И почеу ты думаешь, что для дельфы нет ничего подобного? Насколько я знаю, девэкспрессовцы делают инструменты и для нета и для дельфы, с их кодрашем(бесплатной версией) я знаком, там тоже порядка 50 рефакторингов, а в платной в несколько раз больше и помимо рефакторинга есть еще куча прибамбасов, включая возможность написания плагинов. Если то же самое есть для и для дельфы, то этот пункт тоже можно вычеркнуть.

В дельфе разве нельзя использовать тот же COM?

Винда поддерживает два скриптовых языка и их можно использовать везде, где доступен COM. 

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

Еще раз повторяю: я показал, что в F# для реализации такого запроса никаких дополнительных средств вводить не надо. Запросы в этом языке есть
http://msdn.microsoft.com/ru-ru/library/hh225374.aspx
И то, что я показал - это вовсе не они, а обычные приемы программирования на языке. Я тебе просто показал, как легко в языке реализовать то, что в C# делается через костыль. 

Возьми десяток и увидишь изменится или нет.

Мой пример понятен, а для того, чтобы экстраполировать его на более сложные случаи знатоком языка быть не надо. Кроме того, и ежу понятно, что многократная вложенность функций делает код нечитабельным, в противовес вызову по цепочке. Неужели это надо на пальцах объяснять?

На C# оказывается тоже можно реализовать каррирование 
http://habrahabr.ru/post/76545/