Меня беспокоит, что человек, который защитил докторскую на монадах, считает статическую типизацию бессмысленной и довольно категорично это утверждает. Я не питаю иллюзий относительно своих знаний — они, разумеется, куда меньше, поэтому хочется быть уверенным, что все его резоны достаточно внимательно рассмотрены
«Как и большинство старых Lisp, на первом этапе PSL компилирует код Lisp в код LAP, который является еще одним кроссплатформенным языком. Однако там, где более старые Lisp в основном компилировали LAP непосредственно на язык ассемблера или в какой-либо промежуточный продукт, зависящий от архитектуры, PSL компилирует LAP в код C, который будет выполняться на языке виртуальной машины; поэтому программы, написанные на нем, в принципе так же переносимы, как и C, что довольно переносимо. „
Интересный способ. Меня интересуют различные методы реализации виртуальных машин, надо будет изучить как у них там все устроено
Там далее он упоминает, что собирается попробовать Clojure, и вероятно добавит её к своему стеку.
Вполне вероятно, что в его стеке статическая типизация может казаться (или быть) бессмысленой. Там есть даже причины, почему он так считает, и те, кто знакомы с функциональным программированием сразу смогут предложить зависимые типы в качестве контраргумента для этих причин.
Я сделал этот перевод специально для того, чтобы разнообразие мнений спровоцировало обсуждение
Статья написана хорошо, я бы написал хуже. Читается легко, узнаешь новое.
Кажется, мы делаем всё, чтобы писать хороший код: читаем книги, слушаем подкасты, ходим на конференции и изучаем лучшие практики. Почему же результат оставляет желать лучшего?
Ответ чуть ниже прямо в той же статье:
Конечно, есть разработчики, которые относятся к коду как к искусству, но в основном он нужен бизнесу, чтобы решать бизнес-задачи и позволять людям взаимодействовать друг с другом и с информацией
Результат будет лучше, если вместЕ с подкастами и конференциями, мы будем относиться к (хорошему) коду, как к искусству — а в искусстве, если нашел косяк, не грех и переделать. Для бизнеса же, пока все работает — не трогай. В этом плане проходить по своему когнитому в процессе переписывания, куда полезнее, чем разговаривать на конференциях, потому что, как и написано в статье
… за время нашего разговора, он не может ни увидеть, ни подумать, ни сказать ничего нового. Он может только креативно комбинировать то, чему уже научился.
Ну и, если экстраполировать в будущее, то:
Пятнадцать лет назад обучали ООП, а сейчас Rust и Go считают наследование антипаттерном.
Вангую, что еще через 15 лет мы перестанем…
… говорить джуну: «Тебе надо давать читаемые имена идентификаторам»
… и муштровать его интервальными повторегиями, а вместо этого будем все-таки знакомить его с моделями мышления, подходящими для широкого спектра решаемых проблем: унификацией, зависимыми типами, замыканиями, рекурсией в конце концов.
За ссылки с «свежий взгляд» на онбординг — спасибо.
Главред Хабра может призывать к чему угодно. У него-то мотивация понятна — увеличение базы контента и трафика.
Я не понимаю мотивации для вас. Я бы понял если бы это был ваш материал и вы хотели бы что-то донести до более широкой аудитории.
Но в таком случае автор бы как минимум отредактировал статью «по результатам обсуждения», а не изолировал бы анклавы обсуждения на разных площадках, не давая ссылки.
Кто мешал внизу оставить короткую строчку «обсуждалось там-то»? Без нее все это выглядит как копипаста ради виртуальных плюсиков в карму.
Во-вторых, на RSDN ничего не объяснили, а некоторые даже ничего и не поняли.
Вообще-то это далеко не так, перечитайте обсуждение там
— это не выравнивнивание. Это специальные участки, оставленные для того чтобы облегчить реализацию перехвата функции методом сплайсинга. Когда внешний код хочет перехватить функцию ядра — он записывает туда FAR JMP на себя.
Могу предположить что другие замеченные недостатки также могут иметь какие-то рациональные объяснения.
Например, пример с чтением в EAX и ECX вместо AX и CX может вызвать cache miss, по той причине, что оставшиеся два байта уже не попали в кэш или даже нарушение безопасности, если расширенный регистр будет сохранен в стек, откуда значение может быть прочитано кем-то, кого мы не ждем.
Кстати в обсуждении на RSDN откуда цельнотянута статья — на это указали. Если уж вы занимаетесь копипастой умножая энтропию в интернете, то приводите хотя бы ссылку, чтобы не изолировать обсуждения по анклавам: http://rsdn.org/forum/asm/6251024.flat. Там же, кстати, объяснения всех «несовершенств», читателям статьи будет полезно ознакомиться
Окей, а теперь я бы хотел слинковать с этим какую-нибудь библиотеку (например написанную на ассемблере). И тут у нас появляются GOT и PLT и все становится лишь немного интереснее, а вот возможностей прибавляется в разы. Как насчет продолжить проект? )
Выбор и так довольно широк, Lisp как и некоторые другие языки обычно нужен энтузиастам, которые ищут больше возможностей чем достаточно большинству разработчиков
Интересный способ. Меня интересуют различные методы реализации виртуальных машин, надо будет изучить как у них там все устроено
Вполне вероятно, что в его стеке статическая типизация может казаться (или быть) бессмысленой. Там есть даже причины, почему он так считает, и те, кто знакомы с функциональным программированием сразу смогут предложить зависимые типы в качестве контраргумента для этих причин.
Я сделал этот перевод специально для того, чтобы разнообразие мнений спровоцировало обсуждение
Ответ чуть ниже прямо в той же статье:
Результат будет лучше, если вместЕ с подкастами и конференциями, мы будем относиться к (хорошему) коду, как к искусству — а в искусстве, если нашел косяк, не грех и переделать. Для бизнеса же, пока все работает — не трогай. В этом плане проходить по своему когнитому в процессе переписывания, куда полезнее, чем разговаривать на конференциях, потому что, как и написано в статье
Ну и, если экстраполировать в будущее, то:
Вангую, что еще через 15 лет мы перестанем…
… и муштровать его интервальными повторегиями, а вместо этого будем все-таки знакомить его с моделями мышления, подходящими для широкого спектра решаемых проблем: унификацией, зависимыми типами, замыканиями, рекурсией в конце концов.
За ссылки с «свежий взгляд» на онбординг — спасибо.
Я не понимаю мотивации для вас. Я бы понял если бы это был ваш материал и вы хотели бы что-то донести до более широкой аудитории.
Но в таком случае автор бы как минимум отредактировал статью «по результатам обсуждения», а не изолировал бы анклавы обсуждения на разных площадках, не давая ссылки.
Кто мешал внизу оставить короткую строчку «обсуждалось там-то»? Без нее все это выглядит как копипаста ради виртуальных плюсиков в карму.
Вообще-то это далеко не так, перечитайте обсуждение там
4025AA 90 NOP
4025AB 90 NOP
4025AC 90 NOP
4025AD 90 NOP
4025AE 90 NOP
4025AF 8BFF MOV EDI,EDI
4025B1 55 PUSH EBP
— это не выравнивнивание. Это специальные участки, оставленные для того чтобы облегчить реализацию перехвата функции методом сплайсинга. Когда внешний код хочет перехватить функцию ядра — он записывает туда FAR JMP на себя.
Могу предположить что другие замеченные недостатки также могут иметь какие-то рациональные объяснения.
Например, пример с чтением в EAX и ECX вместо AX и CX может вызвать cache miss, по той причине, что оставшиеся два байта уже не попали в кэш или даже нарушение безопасности, если расширенный регистр будет сохранен в стек, откуда значение может быть прочитано кем-то, кого мы не ждем.
Кстати в обсуждении на RSDN откуда цельнотянута статья — на это указали. Если уж вы занимаетесь копипастой умножая энтропию в интернете, то приводите хотя бы ссылку, чтобы не изолировать обсуждения по анклавам: http://rsdn.org/forum/asm/6251024.flat. Там же, кстати, объяснения всех «несовершенств», читателям статьи будет полезно ознакомиться