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

На скольки компах мое ПО стоит я без понятия, первую мою софтину юзал отдел в 10-15 чел, она там и сейчас работает без каких-либо проблем. Но вообще я от распространения относительно отмазался, т. е. работаю только с теми, кто сопровождает. Само собой таскать на флешке софт для дюжины юзеров мне надоело уже давно, так что автообновление пришлось сделать.

ПО для учета простоев (кто связан с производством, тот знает насколько больная тема) успели внедрить почти по всему заводу, но тут зачем-то решили заказать аналогичное на 1С, адынэсники в общем-то мою базу и вообще все что можно скопировать в рамках 1С, скопировали. За 5 мес. чего-то там реализовали (2 Delphi-программиста то же самое за 2 месяца напишут, и все нереализованное сделают), но так везде и не заменили. Надо поинтересоваться, как там прогресс, если честно, у меня данный проект энтузиазма особого никогда не вызывал из-за постоянного идиотизма у начальства из-за которого приходилось писать и потом выкидывать очевидно бредовый код. Я так понимаю, смысл всего этого в перераспределении денег в чьи-то карманы.

В общем м/б 1-2 пользователя, а может и 100. Практически все с MS SQL.

@Beltar


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

* http://www.fortran.bcs.org/2007/jubilee/fortran.php -- мнение поклонника Алгола

@k0rvin


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

Ну вот смотри: открываем первый попавшийся сорец на джаве -- видим, что код испещрён get/set методами, повсюду инлайновая реализация однометодных интерфейсов, сложение и прочие арифметические операции вызываются через методы и прочее, и прочее. По этому коду сразу видно: синтаксического сахара мало, засахаривание поможет сократить код во много раз. Если открываем первый попавшийся сорец на шарпе -- каковы шансы увидеть файл, наполовину состоящий из LINQ to Objects, причём с нетривиальными замыканиями? Примерно 0%.

Опять же, в .NET фреймворке предпочитают длинные содержательные имена. Но программисту-то никто не запрещает сокращать код так, как ему нравится. Переписываем Enumerable.Range(1, 10).Select(v => v + 1) в Enm.Range(1, 10).Map(v => v + 1) -- и разница с F# становится в 15 символов. Для сравнения: разница между версией на джаве и шарпом -- 60 символов, и в твоём коде ещё нет инициализации списка.

В свете этого добавление лямбд в джаву -- это перспективная затея, которая сильно сокращает код (в абсолютных числах), который повторяется очень часто при активном использовании популярного паттерна Observer/Observable; а сокращение записи лямбд в шарпе -- затея сомнительная, и есть куда более вкусные потенциальные фичи.

Например, я давно мечтаю об extension-everything (сейчас только extension method, есть идея сделать extension property, extension interface и прочее), с нетерпением жду compiler as service (нужно для экспериментального JAML) -- всё это гораздо более приоритетно, чем экономия 15 символов в LINQ.


Что изменилось?


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


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

@Beltar


Итого: софтина для анализа и обработки данных, предназначенная для отдела в 10-15 человек; полувыпиленная недописанная софтина для учёта простоев для неизвестного количества людей в диапазоне 1-100 человек. Из-за глюка в любой из софтин ничего критического не произойдёт. Как я понимаю, юзеры -- они же тестировщики. Судя по тому, что старые версии кода не хранятся, а тесты отсутствуют -- всем вообще пофиг. 1С-ников наняли, видимо, потому что стало не пофиг.  

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

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

После этого ты будешь мне рассказывать, как пишется настоящий софт?

Видимо память мне таки изменила. Папка с 4-ым фреймворком занимает 429 мб. Откуда я взял 800 - я не в курсе  

Тебе нужен пруф, что ЛСД думает? Нет такого пруфа, верь на слово  


Возможно в реализации. Если говорить о линк-запросах, то тут всем известно, что идеи заимствованы из функциональных языков, но вот способ реализации довольно сложен. Давай разберем простой линк-запрос и посмотрим из чего он состоит.
 Если не пользоваться синтаксисом запроса, а просто вызывать функции, то этот же запрос будет выглядеть такУже не так красиво, но все еще ничего и главное похоже на запрос и легко из одного сделать другое. Но, как известно, все это достигается благодаря методам-расширениям, которые добавляются к интерфейсу IEnumerable<T> и реализуют fluent interface, и только за счет этого такая конструкция стала возможной. Если мы посмотрим на тот же самый код, как он на самом деле выполняется, то это уже будет выглядеть совсем не так выразительно.Еле написал и это еще очень простой запрос. Таким образом для того, чтобы реализовать запросы, пришлось добавить методы расширения, реализовать на них фиксированный набор функций и только это дало возможность всю эту глубоко вложенную конструкцию вытянуть в цепочку последовательных действий.
Теперь если то же самое попробавать сделать на F#, то окажется, что для реализации подобной логики нам вообще не понадобится никаких дополнительных телодвиженийВ данном случае абсолютно никаких дополнительных телодвижений вообще не понадобилось. Здесь используется конвейер, работает это просто, левый операнд оператора |> передается как аргумент правому операнду, который является функцией с одним параметром. Здесь в основном функции принимающие два параметра, но один (лямбда-выражение) передается непосредственно и таким образом, благодаря частичному применению мы получаем функцию с одним параметром, которая принимает аргумент с предыдущего этапа конвейера и дальше по цепочке можно выстроить сколь угодно сложный конвейер. Таким образом, для того, чтобы получить эффект подобный тому, который в ооя был получен за счет реализации флюента с помощью методов расширений, здесь можно получить просто объявив функцию с нужного вида. Кроме того, операторы можно придумывать свои собственные и таким образом вносить изменения в логику работы конвейера(например, если есть нужная функция, но параметры в ней объявлены не в том порядке, можно забабхать оператор, который будет работать как конвейер, только при этом менять аргументы местами и т. д.)

Та линк везде можно использовать. С коллекциями приходится работать не только там где сложные вычисления.

В последнее время она изрядно подросла и видимо будет расти и дальше. 

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



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



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



Предсказуемо характеризует Фортран 77, как жалкую попытку приблизиться к Алголу 60.

А ты не мог бы рассказать немного о специфике ресторанного бизнесса? Я просто с ним не сталкивался никогда. 

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

Повторюсь, я не в курсе ресторанной специфики, но, мне думается вот это:

Это совсем не про рестораны же 

Добавлено через 5 минут и 43 секунды

Ты вот на 1С не гони плиз.
у 1С, как платформы, всего две проблемы:
1) Масштабируемость
2) Плохая репутация среди потенциально толковых спецов

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

Добавлено через 12 минут и 30 секунд

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

Это же надругателсьтво  

ПСЫ: но ваще да, прикольно. Дядьвов, спасибо.

В хаскеле - нет. http://ru.wikipedia.org/wiki/Каррирование
В императивных мамонтах используется редко. На хаскеле совсем другой стиль программирования. Например:
Функция, считающая сумму элементов массива, которые больше нуля(используется оператор комбинирования функций, точка).
Или, более сложное:Здесь создается(грубо говоря) список функций [(1 +), (2 +), (3 +)] и применяется к каждому числу из следующего списка. Результат будет такой: [2,3,4,3,4,5,4,5,6]

Алсо кроме каррирования и хаскела, в честь Хаскела Карри назван ещё и язык curry.

Это сообщение отредактировал(а) Bother - 18.5.2013, 05:56

по аналогии на хаскеле:

Это сообщение отредактировал(а) Bother - 18.5.2013, 07:28

Ну стандартную сетку мало кто использует.
В основном что-то вроде cxGrid, DBGridEh, NextGrid, TMS. В общем, вібор есть. Есть и халявные. Все не буду перечислять.

Вот по поводу cxGrid. Новые версии в Server Mode могут обрабатывать по миллиону записей  не теряя свою функциональность



так это только веб-установщик, который тянет потом из интернете остальное, в общем такие программы называют "червь"   

@diadiavova


На сайте мелкомягких указано число 850. У меня папка C:\WINDOWS\assembly\NativeImages_v4.0.30319_32 весит 770. Так что правдоподобно.


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

(Если честно, я вообще предпочитаю fluent синтаксис. По-моему, он нагляднее, чем "а-ля SQL".)


Вот с этого места -- поподробнее.


Уверяю, я использую. Просто не настолько часто, чтобы беспокоиться о 15 лишних символах.


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

@Beltar


Кассовый терминал, все фискальные железки, кухонные принтеры и прочее -- работают за счёт софта. Нельзя просто взять всё, открутить и считать по бумажке. Оно просто не заработает.


Фи, за другими только повторять умеешь. И вообще:

http://sarcasm.jpg.to/

@Zloxa


Можно или работать по "амбарной книге", или пользовать софтом. Поочереди -- не получится. Если половина данных в БД, софт накрылся, и к тебе приходит чувак и говорит, что столик резервировал -- как проверить?

Касса автоматизируется. Официант жмакает на кнопки, на кухонные принтеры отправляются уведомления, списываются запасы, туда-сюда ходят уведомления о состоянии заказа и занятых столиках, за всю деятельность официантам рассчитываются бонусы, всё железо на кассе типа фискальных регистраторов, всяких табло с информацией и прочим работают через софт, видео-наблюдение с привязкой к событиям на кассе (по секрету: воруют везде и по-страшному), постоянная синхронизация данных с сервером, возможность инвентаризации в любую секунду, разнообразные системы скидок, в том числе целая куча от третьих сторон, интеграция с другим софтом типа отельного софта, приходы-уходы с расчётом штрафов, управление кассовыми сменами, различные системы оплаты; в бэкофисах вся экономика ресторана с сотнями отчётов, в том числе OLAP, настройки вплоть до картинок на чеке, всякие взаимодействия с 1С... Опухнуть можно всё перечислять.

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


Это про софт для ресторанов.


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

@Bother


Есть всякие ImpromptuInterface, которые позволяют делать каррирование в шарпе (кроме всего прочего). Но синтаксис, конечно, страшен. 

Добавлено через 1 минуту и 51 секунду
@Akella


Веб-установщик весит 500 КБ. 50 МБ -- это полная "оффлайновая" версия.

Beltar, я тебя прошу вести холивар в более спокойной манере.  

http://forum.vingrad.ru/index.php?showtopi...t&p=2564532
Akella, если бы ты проходил у меня интервью, и я узнал, что ты гитхаба в глаза не видел, я бы тебе не просто поставил самую низкую оценку, я бы тебя пристрелил.
Но к счастью этого не произойдёт, так как ты дельфист а не программист, ты до интервью со мной не дойдёшь, максимум тебе дадут тесты заполнить

Это сообщение отредактировал(а) Felix12321 - 18.5.2013, 09:25

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



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


Вообще с людьми, которые до сих пор сидят на дельфи не всё так просто. Вот не так давно меня попросили проконсультировать как реализовать некий функционал, используя нашу систему. Консультировать пришлось дельфиста, который вроде как перешёл на C#. Он мне сразу сказал, мол, если что то написано плохо, не стесняйся говорить. Но я ему ничего не говорил, так как это даже не индокод это просто насранo, ну в общем то вроде как работает и то хорошо. Я ему объяснил как нормально сделать то что им надо, буквально на пальцах разжевал, он всё равно, по своему,  через жoпу сделал.


Видимо им так ближе   

Это сообщение отредактировал(а) Felix12321 - 18.5.2013, 09:59

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


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


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

Это сообщение отредактировал(а) Felix12321 - 18.5.2013, 10:04

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

Ну фиг знает, вот, например, такая фиготень имеется
http://ru.wikipedia.org/wiki/Microsoft_Rob...eveloper_Studio


Веб-установщик весит пару метров.

На примере линка я показал возможности конвейера. Для того, чтобы в f# это реализовать, нужен только набор функций, в которых результат выполнения одной можно передать другой. Твой красивый синтаксис ограничивается тем, что реализовано в языке, а в f# это обычный приём программирования. 
Взять к примеру математические функции. Вот есть у тебя функция log(a, x) -обыкновенный логарифм, где основание - первый аргумент и cos(x). Как можно вычислить функцию ln(cos(x))? В до-диезе один способ
log(e, cos(x))
Казалось бы просто всё, но здесь уже идёт нагромождение скобок во вложенных выражениях, а если надо будет несколько функций применить, то ты захлебнёшься и тебе придётся либо выносить промежуточные значения в переменные, либо самому реализовывать флюент средствами методов-расширений. В фа-диезе есть следующие возможности записи.
1. аналог приведённого, хоть и скобок поменьше
log e (cos x)
этот вариант прост в случае двух функций, но будет усложняться, если их больше.
2. Конвейер нумер адын
cos x |> log e
всё записывается в той последовательности, в которой будет вычисляться
3. Конвейер нумер два
x |> cos |> log e
Удобно в тех случаях, когда аргумент сам представлен сложным выражением
4. Композиция, мы просто объявим функцию lncos и будем использовать сколько надо
let lncos = cos >> log e
Далее вызов обычный
lncos x



Кстати в третьей версии языка ввели свой линк, но используется он преимущественно для трансляции в sql, поскольку так он вроде как и не нужен.

Так то, что я показал - по сути и есть флюент.