Так ведь с точки зрения грамматики (и вообще компьютера) нет никаких типов, потому что нет вообще семантики, и символы означают только сами себя. Иногда чисто синтаксический взгляд на вещи помогает.
Да? У вас есть 100500 действующих ордеров, идентифицируемых по uint32 orderId. Научите вытаскивать параметры ордера по данному orderId, пожалуйста, без ассоциативного доступа?
Я имел в виду свои задачи. А так вообще в вашей постановке, скорее всего, будет использоваться база данных, и в ней индекс в виде, внезапно, B-дерева.
Фокус на операционной семантике напрочь ломает модульное программирование. Какая мне разница, в какой конкретно код собирается данный модуль, покуда он имеет устраивающие меня характеристики?
Всё бы хорошо, но как это соотносится с вашим заходом про перф абзацем выше? Производительность не задаётся интерфейсом.
Кроме того, я последнее время занимался противоположной вещью - преобразованиями денотационной семантики при сохранении операционной.
Где там это различие возникает?
Да непосредственно из самой концепции типов. Как только вы уходите от старика фон Неймана, всё запутывается до невозможности.
Я, причём, до этого мнения не сразу эволюционировал, именно в силу дурного воспитания. Но слава богу у нас была в институте теория формальных грамматик, которая отчасти расставила всё по местам в голове.
Да, это адово мало. В моих задачах миллиарды лукапов в день (можете посмотреть, сколько там сообщений в день на каком-нибудь NYSE, мне лень), поэтому, склонен считать, у меня есть некоторый опыт работы с системами, где перф на самом деле важен.
У меня тоже есть опыт работы с системами, где перф важен. Вон, целую специализированную железку собирали. Просто ассоциативный доступ в таких задачах не используется.
Интерфейс и выражает логику.
Утверждаю, что хэшмапа — это любой тип, для которого реализуем
Бессмысленно спорить об определениях. Я воспитан в понятиях, что алгоритмы и структуры данных составляют единое целое (у Вирта, помнится, даже книжка такая была) и выражают операционную семантику. А вы пишете про денотационную.
И снова широта образования пошла. Действительно, зачем программисту нужны основы теории типов?
Это большой и очень непростой вопрос, как вы сами отлично знаете.
Я вот лично поклонник бестипового исчисления.
Типизация имеет свои плюсы, но она замусоривает голову на самом глубинном уровне мнимым различием кода и данных. Нет оператора неподвижной точки? Нафиг.
Соответственно, если следовать логике вашей аналогии (сам я не рискую делать какие-то суждения по этой теме), подавляющее большинство программистов благополучно проработает без всяких проблем, не имея фундаментального образования
Я лично про фундаментальные знания ничего не говорил. Это больше к естественным наукам. А обучение инженера заключается в обзоре, систематизации и позиционировании конкретных практик. Не так важно, транспьютер там или не транспьютер. У нас в институте был транспьютер, вот мы его и программировали на параллельном программировании. В МФТИ была какая-нибудь другая фишка. Но это всё - части общей учебной программы. Можно так поделить, можно эдак.
Мне вот, например, алгоритм Брезенхема и прочая машинная графика совершенно не пригодились (пока), а для кого-то это очень важно. Но я по крайней мере о нём знаю.
Никакого смысла специально прерывать соединение я не вижу. Тарифы в городской телефонной сети в то время были безлимитными, а устраивать конкуренцию между банкоматами за дозвон на ограниченный модемный пул банка было бы безумием.
В ваших задачах один лукап на всё время жизни программы?
Ну, допустим, я скажу, что в моих задачах 10 лукапов в секунду. Это как-то меняет дело?
Я замечу, что если у вас производительность упирается в лукапы хешмапа, то вы, скорее всего, неправильно выбрали структуру данных: мап вам, возможно, и нужен, а хеш – нет.
Интерфейс — это всё что важно, просто потому что объекты мы определяем по тому, как с ними можно работать
На интерфейс вообще должно быть плевать. Не нравится заданный – напишите свой враппер. Важна логика.
Кстати, про сабтайпинг нам действительно не рассказывали, а уж тем более про него как отношение.
Узнавать о вещах кроме как из институтского курса невозможно?
Возможно. Однако, во-первых, маловероятно самостоятельно заинтересоваться такой вещью. А во-вторых, что ещё важнее, даже прочтение книжки по языку Оккам не даст практики программирования транспьютера (мы его, кстати, программировали и в институте, и на работе на Си, а не на Оккаме).
Я к тому говорю, что институт в принудительном порядке даёт широкую базу, из которой заранее непонятно, что именно затем выстрелит.
Да, и я не вижу ничего странного в том, что в попадавшихся мне задачах нет разницы между 1 и 30 операциями.
Хэшмапа — это структура с определённым интерфейсом и, если хотите, гарантиями сложности.
Я совершенно не согласен с таким утверждением. Для меня хешмап – это конкретное представление структуры данных в памяти. А интерфейс в этом вопросе – дело десятое (кстати, в каком-нибудь джаваскрипте хешмап может иметь интерфейс массива). Что касается гарантий сложности, то они в практическом смысле очень приблизительны, как я показал выше.
То есть, у вас на практике была сборка транспьютера, но вы говорите, что никакая практика не дала бы вам такой опыт? Вам не кажется, что это, ну, несколько внутренне противоречиво?
Я в институте в курсе параллельных вычислений учился программировать транспьютер. А потом на работе спроектировал другой транспьютер, зная о такой возможности из институтского курса.
И, кстати,
главным конструктором
программист
Программы без железа настолько же мертвы, как теория без практики. Но вообще и в чисто программных продуктах бывает роль главного конструктора.
Я говорю о том, что бездумное использование хешмапов в качестве структуры данных по умолчанию, то есть так, как они реализованы в базовых библиотеках большинства современных языков программирования, приводит к значительным потерям памяти. И это факт.
Чем надо заниматься, чтобы ни разу не уткнуться в большую скорость хэшмап по сравнению с массивами,
Я не предлагал голый массив как альтернативу хешмапу. Но структуры данных не исчерпываются хешмапом и массивом.
По рабочему проекту, конечно (я был главным конструктором). Это завод делал, по фану такую вещь с реально полезной производительностью практически невозможно собрать, там всё упирается в СВЧ.
Я ж написал, что на практике как-то сам собрал транспьютер. Так что пригодилось.
В реальном мире у меня стоят знаки «no parking» там, где парковаться не нужно, бордюры выкрашены красным там, где парковаться не нужно по пожарным причинам, и так далее.
Я уже слышал, что в США практика вождения очень приближена к теории. Но в России (а значит и в общем случае) это не так. Мою машину как-то раз эвакуировали за эти несколько метров.
Хотя я думаю, что вы немного лукавите, и на всё красных бордюров не напасёшься.
Процессор, как грамматика, конечен и разрешим.
А что такое процессор компьютера, как не порождающая грамматика нулей и единиц на выводах?
Конечная, просто очень большая.
Ну нравится человеку поговорить с умными людьми.
Вы вот, допустим, на море приезжаете позагорать тоже без явной цели.
Я к тому, что со скобками не должно бы работать. Вы там перестраховались немножко на входе в
evalсtry.Что-то у вас тут со вложенностью
evalнапутано.А посмотрел я туда, потому что у вас по синтаксису Лиспа лишние скобки в форме
if:(1)по кашруту должно быть без скобок, потому что это не вычислимая форма, а просто литерал1, значение которого равно единице.Так как вы реализовали Лисп-1, то семантика формы
(1)заключается в том, чтобы выполнить значение единицы, то есть число 1, как код. Что невозможно.Так ведь с точки зрения грамматики (и вообще компьютера) нет никаких типов, потому что нет вообще семантики, и символы означают только сами себя. Иногда чисто синтаксический взгляд на вещи помогает.
Я имел в виду свои задачи. А так вообще в вашей постановке, скорее всего, будет использоваться база данных, и в ней индекс в виде, внезапно, B-дерева.
Всё бы хорошо, но как это соотносится с вашим заходом про перф абзацем выше? Производительность не задаётся интерфейсом.
Кроме того, я последнее время занимался противоположной вещью - преобразованиями денотационной семантики при сохранении операционной.
Да непосредственно из самой концепции типов. Как только вы уходите от старика фон Неймана, всё запутывается до невозможности.
Я, причём, до этого мнения не сразу эволюционировал, именно в силу дурного воспитания. Но слава богу у нас была в институте теория формальных грамматик, которая отчасти расставила всё по местам в голове.
У меня тоже есть опыт работы с системами, где перф важен. Вон, целую специализированную железку собирали. Просто ассоциативный доступ в таких задачах не используется.
Бессмысленно спорить об определениях. Я воспитан в понятиях, что алгоритмы и структуры данных составляют единое целое (у Вирта, помнится, даже книжка такая была) и выражают операционную семантику. А вы пишете про денотационную.
Это большой и очень непростой вопрос, как вы сами отлично знаете.
Я вот лично поклонник бестипового исчисления.
Типизация имеет свои плюсы, но она замусоривает голову на самом глубинном уровне мнимым различием кода и данных. Нет оператора неподвижной точки? Нафиг.
Я этого не отрицаю.
Я лично про фундаментальные знания ничего не говорил. Это больше к естественным наукам. А обучение инженера заключается в обзоре, систематизации и позиционировании конкретных практик. Не так важно, транспьютер там или не транспьютер. У нас в институте был транспьютер, вот мы его и программировали на параллельном программировании. В МФТИ была какая-нибудь другая фишка. Но это всё - части общей учебной программы. Можно так поделить, можно эдак.
Мне вот, например, алгоритм Брезенхема и прочая машинная графика совершенно не пригодились (пока), а для кого-то это очень важно. Но я по крайней мере о нём знаю.
Никакого смысла специально прерывать соединение я не вижу. Тарифы в городской телефонной сети в то время были безлимитными, а устраивать конкуренцию между банкоматами за дозвон на ограниченный модемный пул банка было бы безумием.
Ну, допустим, я скажу, что в моих задачах 10 лукапов в секунду. Это как-то меняет дело?
Я замечу, что если у вас производительность упирается в лукапы хешмапа, то вы, скорее всего, неправильно выбрали структуру данных: мап вам, возможно, и нужен, а хеш – нет.
На интерфейс вообще должно быть плевать. Не нравится заданный – напишите свой враппер. Важна логика.
Кстати, про сабтайпинг нам действительно не рассказывали, а уж тем более про него как отношение.
Возможно. Однако, во-первых, маловероятно самостоятельно заинтересоваться такой вещью. А во-вторых, что ещё важнее, даже прочтение книжки по языку Оккам не даст практики программирования транспьютера (мы его, кстати, программировали и в институте, и на работе на Си, а не на Оккаме).
Я к тому говорю, что институт в принудительном порядке даёт широкую базу, из которой заранее непонятно, что именно затем выстрелит.
Да, и я не вижу ничего странного в том, что в попадавшихся мне задачах нет разницы между 1 и 30 операциями.
Я совершенно не согласен с таким утверждением. Для меня хешмап – это конкретное представление структуры данных в памяти. А интерфейс в этом вопросе – дело десятое (кстати, в каком-нибудь джаваскрипте хешмап может иметь интерфейс массива). Что касается гарантий сложности, то они в практическом смысле очень приблизительны, как я показал выше.
Я в институте в курсе параллельных вычислений учился программировать транспьютер. А потом на работе спроектировал другой транспьютер, зная о такой возможности из институтского курса.
Программы без железа настолько же мертвы, как теория без практики. Но вообще и в чисто программных продуктах бывает роль главного конструктора.
Есть такое дело, не спорю.
Я говорю о том, что бездумное использование хешмапов в качестве структуры данных по умолчанию, то есть так, как они реализованы в базовых библиотеках большинства современных языков программирования, приводит к значительным потерям памяти. И это факт.
Я не предлагал голый массив как альтернативу хешмапу. Но структуры данных не исчерпываются хешмапом и массивом.
По рабочему проекту, конечно (я был главным конструктором). Это завод делал, по фану такую вещь с реально полезной производительностью практически невозможно собрать, там всё упирается в СВЧ.
Ну так такая ложная альтернатива стоит именно от недостаточной теоретической подотовки.
Я ж написал, что на практике как-то сам собрал транспьютер. Так что пригодилось.
Я уже слышал, что в США практика вождения очень приближена к теории. Но в России (а значит и в общем случае) это не так. Мою машину как-то раз эвакуировали за эти несколько метров.
Хотя я думаю, что вы немного лукавите, и на всё красных бордюров не напасёшься.