Ортолинейность больше геморрой - реально много времени уходит на привыкание а толку немного. Ничего особенно эргономичного в ортолинейности нет - колонки клавиш под указательным пальцами всё равно две и пальцам приходится двигаться вправо и влево.
Вообще, не только Emacs, в Linux почти везде шорткаты с Ctrl и оно очень неудобно пока не поменяешь Ctrl и Alt местами. Тогда все становится на свои места (да, да space kadett и все такое)
Опять все не там ищут. Конечно, в изначальном ТЗ была подсистема которая визуализирует сигнал датчика. Просто ее не успели сделать и сдали проект как было, убедив заказчика, что для MVP это вполне норм. функциональность. И не докопаешься - подрядчик не виноват, в его документации было всё подробно описано.
Вот поддержу, да. Ощущение такое, что эта вся огромная система написанная на этом языке постоянно в движении и никак не устаканится. В итоге, каждый раз когда нужно сделать что-то не сильно сложное, типа локального шелла с выбранными питоновскими пакетами приходится копировать и править существующий конфиг, запомнить и воспроизвести по памяти так и не выходит.
Особенно это хорошо видно когда пытаешься отладить какую-нибудь проблему - очень так непросто, много слоев всякого.
Я таки подозреваю, что ограничения которые предлагались были связаны именно со сложностью восприятия их кода чем с локальной проблемой типа гигиены. Мало того что там код создает другой код, дык еще и все эти квотинги\анквотинги жизнь проще не делают. Как мне кажется, именно поэтому в scheme попытались как-то исправить эту ситуацию - define-syntax легче воспринимать.
Не, было круче - чуваку нужно было поправить по виду простейший баг который в конце "путешествия" оказался злонамеренной диверсией предшественника в коде компилятора.
Еще в Common Lisp'овых гайдах пытались предупреждать о том, что макросами не стоит злоупотреблять - там где можно функцией обойтись НУЖНО ею обходиться. И вообще, - макрос только если всем участникам очевидно что получилось удачно. При этом, к сожалению, какого-то более простого критерия уместности макроса никто так и не придумал :(
По-моему, в F# была подходящая фича которую не спешат тянуть в другие языки - единицы измерения в качестве модификатора типа. Фича позволяла без особой когнитивной нагрузки избежать ошибок когда метры могут быть в качестве килограммов использованы.
Ну дык на дейликах происходит ровно то же самое. Все прекрасно успевается до тех пор пока в планируемую дату завершения не становится понятно что не успевается.
И от "напишет херню" дейлики никак не спасают - код на слух очень плохо воспринимается. Для этого, сколько помню, код ревью придумали.
Вот всему руками поддержу. Давно пора уже перестать разрабатывать все эти скучные и унылые продукты. Если кому такое надо, пусть они, как-нибудь, сами, там, что-нибудь, в экселе копошатся!
А вы не пробовали работу как-то по-другому организовать? Ну, знаете, там, аналитики бывают всякие, продакт овнеры и т.д. Ну, чтобы, когда разработчик что-то начинает разрабатывать уже было понятно что и зачем он делает.
Мне интересно было что-то делать на ассемблере КМ1801 (PDP-11 который) и КР580 (Интел 8080, вроде). Тогда вообще все происходящее на тех компьютерах укладывалось в одной голове и ассемблер был вполне органичен. В MSDOS, пожалуй тоже. А вот что-то делать в системах типа винда на ассемблере, имхо, странно.
Я, когда проделал аналогичное упражнение на винде, - приложение на ассемблере создавало окно используя win api, испытал странное чувство что я сделал какую-то фигню, но не мог понять почему. А потом меня озарило. Я вспомнил споры со своим другом - аудиофилом. Аргумент про дорогучий силовой кабель из бескислородной меди (тут про технологию точно соврал, но деталей не помню) который ну никак, ни за какие деньги не сможет исправить кривое электричество которое было погнуто в процессе передачи по километрам зоопарка проводки от электростанции до розетки.
Не понял. Т.е. очевидно, если у нас монолит, то чтобы получить систему нужно реализовать весь необходимый функционал. А в микросервисах есть какая-то магия которая позволяет получить систему реализовав не весь функционал?
Про терабайты памяти. Видимо, помимо магии микросервисов за бортом моего понимания остался негласный запрет разбивать конечную систему на разумное количество составных частей. Так, чтобы все не было в одном процессе, но и не создавать себе ад - необходимость оркестрации сотен составных частей. Т.е. должен быть или обязательно монолит, или микросервисы (если я правильно помню, микро - миллионная часть).
А объясните мне, за счет чего в микросервисах можно "грамотно все объекты и методы спроектировать" а в монолите нельзя? Тут какая-то логическая ошибка. Если кто-то не может грамотно разделить отвественность по функциональным единицам в тепличных условиях монолита, то в более сложных условиях с сетевым взаимодействием он и подавно не сможет.
А с ортолинейностью это как связано?
Ортолинейность больше геморрой - реально много времени уходит на привыкание а толку немного. Ничего особенно эргономичного в ортолинейности нет - колонки клавиш под указательным пальцами всё равно две и пальцам приходится двигаться вправо и влево.
Вообще, не только Emacs, в Linux почти везде шорткаты с Ctrl и оно очень неудобно пока не поменяешь Ctrl и Alt местами. Тогда все становится на свои места (да, да space kadett и все такое)
А что с Орбакайте-то случилось??
Опять все не там ищут. Конечно, в изначальном ТЗ была подсистема которая визуализирует сигнал датчика. Просто ее не успели сделать и сдали проект как было, убедив заказчика, что для MVP это вполне норм. функциональность. И не докопаешься - подрядчик не виноват, в его документации было всё подробно описано.
Вот поддержу, да. Ощущение такое, что эта вся огромная система написанная на этом языке постоянно в движении и никак не устаканится.
В итоге, каждый раз когда нужно сделать что-то не сильно сложное, типа локального шелла с выбранными питоновскими пакетами приходится копировать и править существующий конфиг, запомнить и воспроизвести по памяти так и не выходит.
Особенно это хорошо видно когда пытаешься отладить какую-нибудь проблему - очень так непросто, много слоев всякого.
Знание греческого алфавита явно не помогает понять молодое поколение :)
Я таки подозреваю, что ограничения которые предлагались были связаны именно со сложностью восприятия их кода чем с локальной проблемой типа гигиены. Мало того что там код создает другой код, дык еще и все эти квотинги\анквотинги жизнь проще не делают. Как мне кажется, именно поэтому в scheme попытались как-то исправить эту ситуацию - define-syntax легче воспринимать.
Не, было круче - чуваку нужно было поправить по виду простейший баг который в конце "путешествия" оказался злонамеренной диверсией предшественника в коде компилятора.
Еще в Common Lisp'овых гайдах пытались предупреждать о том, что макросами не стоит злоупотреблять - там где можно функцией обойтись НУЖНО ею обходиться. И вообще, - макрос только если всем участникам очевидно что получилось удачно.
При этом, к сожалению, какого-то более простого критерия уместности макроса никто так и не придумал :(
По-моему, в F# была подходящая фича которую не спешат тянуть в другие языки - единицы измерения в качестве модификатора типа. Фича позволяла без особой когнитивной нагрузки избежать ошибок когда метры могут быть в качестве килограммов использованы.
Ну дык на дейликах происходит ровно то же самое. Все прекрасно успевается до тех пор пока в планируемую дату завершения не становится понятно что не успевается.
И от "напишет херню" дейлики никак не спасают - код на слух очень плохо воспринимается. Для этого, сколько помню, код ревью придумали.
Вот всему руками поддержу. Давно пора уже перестать разрабатывать все эти скучные и унылые продукты. Если кому такое надо, пусть они, как-нибудь, сами, там, что-нибудь, в экселе копошатся!
А вы не пробовали работу как-то по-другому организовать? Ну, знаете, там, аналитики бывают всякие, продакт овнеры и т.д. Ну, чтобы, когда разработчик что-то начинает разрабатывать уже было понятно что и зачем он делает.
Мне интересно было что-то делать на ассемблере КМ1801 (PDP-11 который) и КР580 (Интел 8080, вроде). Тогда вообще все происходящее на тех компьютерах укладывалось в одной голове и ассемблер был вполне органичен. В MSDOS, пожалуй тоже. А вот что-то делать в системах типа винда на ассемблере, имхо, странно.
Я, когда проделал аналогичное упражнение на винде, - приложение на ассемблере создавало окно используя win api, испытал странное чувство что я сделал какую-то фигню, но не мог понять почему.
А потом меня озарило. Я вспомнил споры со своим другом - аудиофилом. Аргумент про дорогучий силовой кабель из бескислородной меди (тут про технологию точно соврал, но деталей не помню) который ну никак, ни за какие деньги не сможет исправить кривое электричество которое было погнуто в процессе передачи по километрам зоопарка проводки от электростанции до розетки.
А X сервер-то здесь зачем - тот еще монстр?
Чем писать в видеопамять напрямую плохо-то?
А меня значительно больше порадовал упоминаемый в статье DreamBerd. Всем рекомендую!
Не понял. Т.е. очевидно, если у нас монолит, то чтобы получить систему нужно реализовать весь необходимый функционал. А в микросервисах есть какая-то магия которая позволяет получить систему реализовав не весь функционал?
Про терабайты памяти. Видимо, помимо магии микросервисов за бортом моего понимания остался негласный запрет разбивать конечную систему на разумное количество составных частей. Так, чтобы все не было в одном процессе, но и не создавать себе ад - необходимость оркестрации сотен составных частей. Т.е. должен быть или обязательно монолит, или микросервисы (если я правильно помню, микро - миллионная часть).
А объясните мне, за счет чего в микросервисах можно "грамотно все объекты и методы спроектировать" а в монолите нельзя?
Тут какая-то логическая ошибка. Если кто-то не может грамотно разделить отвественность по функциональным единицам в тепличных условиях монолита, то в более сложных условиях с сетевым взаимодействием он и подавно не сможет.