Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет superbatman1488 ([info]anon123)
@ 2016-09-01 17:16:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
технологии
как заебало это блядское слово в применении к программированию, означает что угодно, только не "облегчение жизни"
примерно как "практичный" означает "уёбищный", "неюзабельный"
предлагаю вместо него использовать "костыли", "велосипеды", "грабли", "модный кусок говна"


(Добавить комментарий)


[info]ketmar
2016-09-01 20:47 (ссылка)
есть ещё более отвратительное, по‐моему: «экосистема».

(Ответить) (Ветвь дискуссии)


[info]anon123
2016-09-01 21:03 (ссылка)
экосистема - это хотя бы не так контринтуитивно и что-то обозначает
то есть отвратность понятия примерно на уровне "code smells"
(боюсь думать, как это перевели)

а технологии, и следующая за ними пурга про "новые технологии", "надо изучать новые технологии"
совершенно дезориентирует

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-02 08:27 (ссылка)
да тоже ничго не обозначает. лично я при прочтении этого слова сразу вижу кучу дебилов в свитерах с оленями.

а «новые технологии» — согласен, чистый маркетинговый бред. какие, в жопу, новые — ничего нового с семидесятых годов не придумали.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-02 16:53 (ссылка)
про свитера здорово! но однако ж экосистема означает, что тебе с ними жить, имитировать их повадки и прочее говно

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-02 16:54 (ссылка)
ну если командная разработка

(Ответить) (Уровень выше)


[info]ketmar
2016-09-02 17:24 (ссылка)
да нифига. вот поэтому слово и токсичное: на самом деле нахуй не нужно ничего имитировать и куда‐то «вписываться». если оленям нравится — пусть хоть рогами в зад ебутся по чётным дням, но ты‐то какое к этом отношение имеешь?

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-02 20:31 (ссылка)
очень зависит.
если всё со всем связано, проект написан до тебя и тебе надо что-то допиливать с другими людьми, и всё это с код-ревью, то приходится мимикрировать или валить
какой-нибудь фреймворк и сверху него ещё один и ещё один и библиотеки библиотеки и оно всё со всем связано и выбрано до тебя и тебе надо постоянно задумываться над тем, как блджад заставить вот эту хуйню с этой работать, сидишь в гугле и прочее
то есть когда непонятно, как в рамках существующей кодобазы что-то добавить или убавить, тогда начинаются митинги, постоянное общение программистов между собой и прочее говно
(обычно если есть какие-нибудь упоротые ООПэ-фанаты-любители аспектно-ориентированного метапрограммирования или тон задают те, кто уже в этой секте-экосистеме)

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-03 08:54 (ссылка)
проблема даже не во фрэймворках, а в том, что в подобных проектах обычно никто программировать не умеет. понты кидать кое‐как умеют, слова новые зубрить умеют, а вот с собственно программированием всё очень, очень плохо.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-03 18:44 (ссылка)
да, точно, как бальзам на душу

и я не мог осознать долгое время, почему у меня неприязнь к работе, коллегам, к их подходу
в интернетах, как мне показалось, 99% текста про программирование написано в таком духе
и задачи обычно несложные, но решаются каким-то диким оверинжинирингом
надеюсь что на новом месте будет по-другому

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-03 19:04 (ссылка)
а всё потому, что на Отцов забили. вплоть до анекдотического из реальной жизни таки: «эту задачу невозможно решить, потому что мы не нашли библиотеки, которая это делает».

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-04 11:06 (ссылка)
ну у них свои авторитеты, всё вместе очень похоже на шаманские практики

кстати, исходя из того, что я у тебя читал, тут под Отцами подразумевается Вирт?
или Хоар/Дейкстра/Стретчи/(Абельсон/Сассман)/Милнер/Ершов/Перлис/Кей?
очень много громких имен, поэтому неясно, в какую сторону смотреть

вот Пайк вроде бы отец, но язык GO в 21 веке сделать, это пиздец, по-моему
особенно показательно сравнить его с тем же Джоном Бэкусом,
который на тьюринговской лекции 77 года уже говорил, что
так жить нельзя, и за функциональное программирование топил

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-04 11:21 (ссылка)
все, в общем‐то, из 70-х и начала 80-х. Пайк тоже Отец. немножко впал в маразм, но ему можно. Стили вон жабу придумал — но это ему за схему тоже прощается.

так что все тобой перечисленные — Отцы. просто дело такое, что стоя у истоков, почти автоматически превращаешься в Отца, потому что ничего ещё не придумано. а дети потом «замшелое говно из семидесятых» игнорируют, и в итоге радостно изобретают велосипеды то с треугольными колёсами, то вообще вмурованые в бетонную плиту.

p.s. ты МакКарти забыл. лисп же!

p.p.s. а Вирт, кстати, показал, как надо делать компонентные системы — но никто этого традиционно не заметил. хотя по юзабельности оберон с его гаджетами до сих пор без проблем всех рвёт в куски. а BlackBox Component Builder был мегаохуенен (и я таки когда‐нибудь сделаю его на дишечке).

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-04 11:40 (ссылка)
Ну их дофига же, можно до вечера перечислять: Маккарти там, Турчин, Айверсон

Гай Стил кстати её не придумал, его позвали стандартизовывать просто,
так-то он потом фортресс придумал(который тихо в безвестии сдох)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-04 11:43 (ссылка)
то есть он потом, кажется, говорил, что жава - это великое достижение,
потому что теперь языки со сборкой мусора - мейнстрим
типа ещё чуть-чуть и настанет лисп

(Ответить) (Уровень выше)


[info]ketmar
2016-09-04 11:44 (ссылка)
ну, фактически придумал. там до него была страшная куча говна, а он из неё няшную тачечку говна сделал.

(Ответить) (Уровень выше)


[info]ketmar
2016-09-04 11:25 (ссылка)
как простейший пример: Отцы Томпсон и Пайк популяризовали регулярные выражения, и делали их на автоматах. дети забили на автоматы болт и ударились в рекурсивные реализации, которые атомно сосут. а через двадцать лет один умный молодой человек вдруг решил посмотреть, как это делали в «замшелых восьмидесятых» и офигел.

(Ответить) (Уровень выше)


[info]anon123
2016-09-04 11:37 (ссылка)
тем более, скажем, какие-то надежды Дейкстры и Хоара, допустим, осуществились
(типа языки со ссылочной прозрачностью, насколько это в принципе возможно, и без нуллов)
и если я, чисто гипотетически, на них пишу, то в какую сторону смотреть?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-04 11:46 (ссылка)
да хер знает. во все стороны лучше смотреть, а то чего полезного пропустить можно.

вот мне, например, дико жаль, что StrongTalk откинул ласты. и Self.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-04 12:03 (ссылка)
вот сколько смотрел в сторону смоллтока, в упор не мог понять, в чем пойнт
и соответственно смысла ООП тоже не понимал
(а selling-point'ы ООП обычно - это обычно какой-то буллшит)

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

писал на руби, говорили что похоже на смоллток, не уверен что лучше жавы
(хотя стандартная библиотека очень приятная, и блоки более-менее ок, но типизации не хватает)

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

есть какое-то руководство, чтобы понять крутость смоллтолка?
blue book какая-то совсем огромная
или что на нем можно написать, чтобы стать адептом?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-04 13:14 (ссылка)
всё дело в том, что ООП и то, что сейчас называют ООП — это две никак не связаные вещи.

ООП как его придумал Алан Кей — это ровно два слова: message passing. всё. есть Нечто, оно умеет отвечать на сообщения. это объект. больше нет ничего.

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

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

соответственно, всё состояние инкапсулировано внутри самого объекта, никто снаружи там ковыряться не может.

как видишь, никаких «типов» тут нет. StrongTalk их добавляет, но очень ненавязчиво, не ломая концепцию.

я, в общем‐то, только что описал весь смолтолк, вообще весь. объекты и сообщения. всё, больше там ничего нет.

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

также очень просто делаются «прокси‐объекты», которые просто диспатчат сообщения дальше (или меняют и диспатчат, или…). без особого труда делается сетевая прозрачность (фигле, все аргументы сообщений тоже объекты, так что если они умеют себя передавать по сети, то программеру уже похеру, где конкретно объект, а где тупой проксь, который по сети, например, запросы шлёт). и много других прикольных вещей.

а лучший способ научиться — поставить какой‐нибудь Pharo, и вперёд по Pharo by example, например. сначала будет немного необычно всё, но потом дико попрёт.

собственно, смолтолк — это «oberon extreme»: вообще полностью компонентная система. в обероне ещё видны ошмётки некомпонентности, а в смолтолке просто невозможно писать как‐то иначе.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-04 15:25 (ссылка)
круто, примерно понятно, нужно думать про это
типа поток сообщений и объекты их передают
нет классов, нет наследования, нет

если система побита на большие объекты, её в теории можно произвольно распараллеливать,
типа каждый объект в отдельном процессе/потоке или на разных серверах

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

буду смотреть, спасибо!

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-04 15:32 (ссылка)
да, смолтолк несколько тормозной сам по себе — за счёт глобального динамического диспатчинга. это, впрочем, в современных VM подчитеривают. как и математику (да‐да, это именно в смолтолке придумали «всё на свете объект, даже число!»).

а так да: message passing — ключ к распараллеливанию.

конечно, передача сообщения объекту в смолтолке выглядит почти как обычный вызов метода, и обработчики сообщений делаются очень похоже, но это всё ещё сообщения. внутри оно формирует «селектор», который является именем сообщения, список аргументов, и ищет, есть ли в объекте обработчик этого селектора. если нет, то и это можно обработать. ;-) ну, и посылать произвольно скрафченые сообщения тоже не проблема.

(Ответить) (Уровень выше)


[info]ketmar
2016-09-04 15:36 (ссылка)
p.s. классы, в общем‐то, там есть, но на деле это просто обычные объекты, которые умеют создавать свои инициализированные копии. а в целом какой‐нибудь класс Bag — он тоже объект, его можно как и любой другой объект подвергнуть интроспекции и всё такое. можно даже создать ещё один экземпляр этого класса, который будет такой же, как оригинал (только неясно, зачем).

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-04 17:01 (ссылка)
да, очень похоже на, кажется нелюбимый тобой, руби
там это всё есть, и method_missing, и классы-как-объекты, и числа-объекты

или на FRP какое-нибудь, или эвентсорсинг

но получается что в однопоточном виде оно и не нужно почти никогда
а в многопоточном сделали JADE/akka/erlang и прочие штуки для мультиагентных систем

или какую-нибудь операционную систему интересно в таком подходе написать
(вроде как у смоллтолка была какая-то такая уже, наверное и в лисп-машинах оно похоже работало)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-04 17:08 (ссылка)
я к руби почти никак не отношусь. ну, смолтолк для дебилов — так дебилам тоже надо на чём‐то писать, они не виноваты.

>но получается что в однопоточном виде оно и не нужно почти никогда
ты не туда смотришь немного. смолтолк и message passing — это не про то, как «сделать сетевое», это про то, как вообще писать программы. forth меняет восприятие, scheme, smalltalk. то, что оно позволяет ещё и распределённые вещи делать легче — это бонус, последствия дизайна, а не цель.

>вроде как у смоллтолка была какая‐то такая уже
ага. называлась smalltalk. потому что он изначально спокойно работал на железе без прокладок, это потом его портировали на прокладки.

(Ответить) (Уровень выше)


[info]ketmar
2016-09-04 17:12 (ссылка)
p.s. подумал мылсь, кстати: большинство современных вещей в программинге говно именно потому, что они заточены на решение одной задачи. типа «пишем распределённые сетевые системы». «пишем ещё какую‐то хуйню XYZ». поэтому их дизайн однобок и ограничен.

тот же смолтолк делали иначе: «а давайте захуячим всё объектами и посмотрим, какие ништяки из этого проистекут!» проистекло много разных крутых вещей, причём из совершенно разных областей, и, тащемта, в виде бонусов, а не целей. этого вот у жестоко заточеных систем никогда не будет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2016-09-04 17:53 (ссылка)
да, похоже что так, типа как с математикой
просто я не понял на самом деле эзотерической штуки
получается что нужно думать в терминах мессадж-пассинга, а на чем пишешь - не так важно

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2016-09-04 18:00 (ссылка)
>получается что нужно думать в терминах мессадж‐пассинга, а на чем пишешь - не так
>важно

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anon123
2019-04-30 17:13 (ссылка)
получается во всём виновата конвенция 1 файл - 1 класс, спизженная жавой у оберона. хотя уже в плюсах всё было сложно с этим, но с этой конвенцией уже совсем не смоллтолк, а какой-то tedious monologue получается

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ketmar
2019-04-30 17:21 (ссылка)
ну, оберон и смолтолк вообще имели понятие «файл» постольку поскольку. собственно, в смолтолке его и вовсе нет (для исходников, в смысле), а в обероне плоская система, и основа всё равно документ.

в жабе, видимо, надеялись на то, что иде всё порешает. а она как-то не очень порешала. потому что есть огромная разница между редактором в «живой» системе, и внешней иде.

(Ответить) (Уровень выше)


[info]anon123
2016-09-04 18:03 (ссылка)
вот тут с толку сбивает конвенция "1 файл - 1 класс"
потому что очень сложно думать о мессадж-пассинге и потоке управления в таком стиле

(Ответить) (Уровень выше)