Pull to refresh
0
@MacInread⁠-⁠only

User

5
Subscribers
Send message
Неа, мимо. «Митап», «колл» — правильные американизмы, англицизмы. «Дизайн» в данном контексте — неверно используемое слово. Примерно как «мы продаем нашу экспертизу». Т.е. слово-калька уже используется в языке, и имеет иной смысл.
Почему «дизайнер»? Design != дизайн.
[англ. design — проектировать, конструировать] — художественное конструирование предметов, изделий; создание эстетического облика среды.

To design = разрабатывать, designer в этом контексте = разработчик. Инженер в конце концов.
Я рассматриваю Delphi как 2 языка в одном, и второй, менее мейнстримный язык, очень привлекателен. В первом языке — ручное управление памятью, единоличное владение и try…finally для объектов, а во втором — счётчик ссылок и RAII

Золотые слова. Именно этот баланс, возможность когда надо, ковыряться руками, а когда не надо — доверить компилятору и привлекает.
Оракл, насколько я знаю.
от которого Вирт открещивается как только может, а из-за возможности лепить кнопки на форму

Опять эти стародвание байки про «ляпнул кнопки на форму и готово». Откуда? Я СЕМЬ лет пишу на Дельфи по работе. За эти семь лет у меня было ровно 2 (ДВА) таска, связанных с окнами. Больше ничего связанного с UI не было вообще — серверная часть.

Я хочу, например, иметь обобщенные списки и вообще полноценные коллекции объектов, хочу перемещаться по ним как положено, при помощи итератора, а не как этому вашему компилятору взбредет в голову

Есть коллекции в этом языке. Итератор — спорная вещь.
«Все суть объекты» и не требует полноценности. В принципе, реализацией вашего видения можно считать микроядро. А так — «все суть объекты» — например, NTшный девиз — те же интерфейсы.
У Нордеа клиентов чутка побольше. Представьте себе Сбер на Постгрес.
Не таких и больших. Студентам — да, не потянуть, фирмам — никаких проблем вроде.
Я о том и говорю: они потеряли свою нишу. Под «развивались» имеется в виду не только feature'и, но и увеличение стабильности. У нас в свое время хотели при появлении новой версии перейти на нее с Delphi 7, но оказалось, что IDEшка тормозная и глючная, компилятор медленее, код хуже оптимизирован. Плюс сверху проблемы с unicode'ом. В итоге от перехода отказались, так ядро и пишем на семерке.
Мертвым он не является, но вот свою нишу они в первой половине-середине 2000х упустили. Пока другие (тот же net) развивались, Дельфи стоял на месте.
Вы так говорите, как будто это что-то плохое.
[Почти любая] инструкция предполагает оперированием понятиями, которые в эту инструкцию не входят.

Это не делает ее неимперативной.

Программирование же — это составление инструкций для абсолютного кретина, который не обладает.

Хм… при этом императивного кретина в жизни представить может каждый, а вот функциоанльного — только под ЛСД.
Ни концепций, связанным с функциональным программированием, ни концепций, используемым императивным в жизни обычного человека нет.

Большая часть жизни — императивна, см. пример с дверью. У любого человека. Упомянутый вами фактор субъективизма никакого отношения к обсуждению «императив вс функционал» не имеет. Возьмите не готовку, а кипячение воды в чайнике. Стирку. Совершение покупок. Все императивно, ничего фнукционального нет. Вообще.
Это просто кажется, что какой-нибудь «сборник рецептов» — это «почти программа». Выглядит похоже, но строчка, которая встречается почти в каждом рецепте — перечёркивает всё напрочь. Магическая строчка, выгрядит весьма невинно:

соль, перец — по вкусу

Не просто кажется, а так и есть. Эта строчка применяется императивно: строго после шага n, когда вкус блюда сформирован и его можно ощутить. Не функционально, а строго после шага n.

Потому убедить ученика в этом становится всё сложнее — но это критически важный момент.

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

В результате оказывается что при попытке пройтись по цепочке ИП->ООП->ФП слишком многие не доходят до конца.

Разговор немного идет по кругу.

Это, возможно, вызвано тем, что некоторым людям в прицнипе тяжело осилить ФП, в отличие от ИП, которое встречается в жизни, см. пример с дверью. В силу неспособности понимать абстракции (коими является ФП) в принципе.

императивный код->ФП-представление внутри процессора->ФП-железо

Представление внутри процессора императивно, железо функционально тоже только условно: есть скорость распространения сигнала.

В идеале от императивности нужно бы отказаться вообще,

Это невозможно: все вокруг императивно. Комбинационные схемы в ЦП переключаются императивно, что приходится выравнивать тактированием. Даже если вы возьмете аналоговый компьютер, все равно столкнетесь с проблемой выравнивания фаз.
Это у Ньютона время в одну сторону течёт. А вот теория относительности — вносит поправки: там уже далеко не для всех событий можно сказать — что произошло раньше, что позже.

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

Это если мы в гордом одиночестве, да. А вот если у нас открывает дверь Вася, а заходит туда Маша — то она запросто может и «огрести» если Вася зазевается.

Не имеет значения. Это просто два последовательных процесса, выполняемых двумя «ядрами». То, что они действуют параллельно, не отменяет того, что каждый последователен в действиях.

Это так в 60е годы было. А сейчас у вас уже в кармане — телефон, где процессор ни разу не исполняет «команды одну за другой» и где «Вася» и «Маша» должны прилагать специальные усилия для того, чтобы в дверях не столкнуться.

Исполняет так же. Реордеринг, переключение задач — частности. Суть та же — сначала одна команда, затем другая. Деже если это одна команда задачи А, потом одна команда задачи Б. В некоторый промежуток времени, квант, задача последовательна. Переключение — абстракция, каждое ядро исполняет команды императивно.

Как ни крути, объяснить императивный подход на примере двери с 1м человеком, а потом — борьбу двух императивных процессов за разделяемый ресурс на пример двоих проще раз так в 500, чем фнукциональную парадигму. И математика тут не поможет: человек решает задачу(пример, уравнение) последовательно, действиями (это, кстати, контр-пример к вашему «мы мыслим функционально»).

Но стоит вам запустить реальный интерпретатор — и у вас возникнет совсем другое ощущение.

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

Последние лет 20 разработчики железа вбухивают колоссальные средства в то, чтобы поддерживать иллюзию «императивного железа».

Не императивного железа, а машины. Да, сигнал распространяется параллельно, но мы с ним не работаем. Машина, самый глубокий уровень, который трогают руками — это машинный код (в крайнем случае, микрокод), и здесь все последовательно. У нас есть синхросигнал — аналог того самого времени, которое течет в одну сторону, который обспечивает выполнение шаг за шагом.

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

Затем что в обозримом (субъективное словечко, алярм) будущем не предвидится массового отказа.
Получается, что ф.п. — это абстракция над императивной машиной, которая является абстракцией над неимперативным железом.
Это пока что еще один уровень абстракции.

Не откроет

Значит, я путаю с каким-то другим файловым менеджером, но не суть, я думаю, довод понятен: окно против целого блока.

Кокретнее — в его 5й версии. Правда началось это с 4'й (где появился NCZIP), но апофигей — это 5я.

Ага, это было печально, когда он перестал влезать на дискету. ЕМНИП, 5ю версию переписали на другом языке, поэтому она такая пухлая.
Ой ли? Я видел кучу людей, которые при описании того, что такое «список»

Мне кажется, подразумевается императивный подход как таковой — он действительно ближе человеку, является прямым аналогом инструкции по выполнению каких-либо действий; вместо списков могут использоваться массивы (на ранней стадии, естественно). Само слово «список» дезориентирует новичка, потому что бытовое «список» аналогично массиву.

Мыслим мы как раз функционально. Вот говорим мы императивно, пишем тоже — потому что у нас одна глотка и пара рук.

Хорошо. Примем на секунду вашу точку зрения; что это меняет? Процессор — императивен, выполняет команды одну за одной. Функциональные языки, как и логические — это абстракция. Протекающая иногда (отсечение в Прологе, например).
Сама жизнь императивна: время течет в одну сторону. Мы не можем сначала пройти в дверь, а потом открыть ее.

Это — как раз учебный язык, которые идёт не со стороны того, что в компьютере есть, а со стороны того, что нам от него нужно.

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

как правило, потом достаточно легко осваивают и Pascal и C++ и любые другие языки.

Потому что они ближе и машине, и человеку. Здесь ошибка выжившего: человек, который освоил более абстрактную штуковину, скажем так, «лучше мыслит», поэтому ему легко дадутся императивные языки. Тот, кто мыслит «похуже» (слабо тренирован в обучении), все равно освоит императивную парадигму, а вот на функциональную «мозгов не хватит». Получается иллюзия того, что в первом случае функциональный подход «открыл чакры».
Ага, еще забавно было видеть примеры в учебниках по программированию вида «создадим простейший редактор текста. Вот у нас строковая переменная, читаем в нее файл...». И возникает внезапный прикол, что во-первых эта программа отожрет памяти по размеру файла, при том, что мы видим в каждый момент времени только «окно», а во-вторых, будет доооолго открывать этот файл. При этом какой-нибудь Volkov Commander откроет и отредактирует тот же 1Гб файл в реальном режиме.
потом кеши добавляются и так далее — к моменту, когда мы добрались до JS у нас уже десятки слоёв абстракций — и все они могут нам аукнуться.

Самое неприятное то, что чем больше слоев абстракции, тем сильнее будут «протечки» и тем меньше у нас контроля над ними. Потому что, собственно, абстракция призвана нам его не дать. И протечка будет решаться либо силами самой абстракции — а значит, долго и плохо, либо с помощью использующего ее, и тогда абстракция перестает быть таковой.
А если забыл, ввиду того что не пользовался этим C/C++ с того самого первого курса?..

Это субъективно, конечно, но на мой взгляд, это некое базовое знание, примитив к тому же. Если отложить в сторону JS, то даже в той же Java понятно, что объект создается не из «пустоты». Более того, вопросы работы с памятью входят в экзамен на самый начальный сертификат.
Язык, которым мы пользуемся — это только инструмент, принцип работы кучи (условно) — это знание, которое не зависит от инструмента.

Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные. Я имел ввиду больше 2ое.

Не знаю… нам давали это на первом курсе, в упрощенном виде (список свободных блоков, дробление, фрагментация и т.п.), но общее представление это дает всем — проще быть не может.
При чем здесь «есть другие языки»? Джун — это уровень квалификации — «начальный», т.е. человек без опыта, но с базовым набором знаний. Выделение памяти — в пределах первого курса любого ВУЗа. Если человек закончил ВУЗ по профилю и не знает про выделение памяти, то ему стоит выкинуть свой диплом. Если не учился и не знает, то он просто не обладает достаточной квалификацией, чтобы быть «джуном».

Information

Rating
Does not participate
Registered
Activity