AT
ну а все же где эта граница между обычным асмом, и какими-то командами процессора которые приближены к командам виртуальной машины ява ?
В головах. 🤷♀️
Size: a a a
2021 February 09
AT
Вы же знаете разницу между "Языком Ассемблера" и "машинным кодом"?
AT
И, наверное, в курсе, что процессор декодирует команды машинного кода в "микрооперации"?
JS
и гоняет Minix
AT
ну а все же где эта граница между обычным асмом, и какими-то командами процессора которые приближены к командам виртуальной машины ява ?
Кстати говоря, команды Java-процессора не "приближены" — он тупо реализует команды JVM-байткода.
AT
и гоняет Minix
Некоторые гоняют L4, но это уже частности. 😊
SL
Кстати говоря, команды Java-процессора не "приближены" — он тупо реализует команды JVM-байткода.
которые развоврачиваются в микро команды .. ага знаю ) . ну короче все эти процессоры по сути декораторы над другими процессорами с реальным микрокодом команд )
AT
которые развоврачиваются в микро команды .. ага знаю ) . ну короче все эти процессоры по сути декораторы над другими процессорами с реальным микрокодом команд )
Ага, и в чём проблема? 😃
Кстати, термин "микрокод" другое означает. Хотя кто теперь про такое помнит? 😒
Кстати, термин "микрокод" другое означает. Хотя кто теперь про такое помнит? 😒
SL
да нет проблемы )
Y
совсем разные языки. Там же общего - только краткость синтаксиса
Общего — метаязыки
AN
ну наверно еще как минимум форт-примитывные операции должны быть уже в железе реализованы .. иначе это процессор с двумя стеками .. кстати очень удобно
не знаю как на современных, на 8080 call клал адрес возврата на один стек-данных, и потом начинались танцы с бубнами
не знаю как на современных, на 8080 call клал адрес возврата на один стек-данных, и потом начинались танцы с бубнами
современные тоже многие страдают таким.
AN
ну просто плюшка лиспа - нетипизированное лямбда исчисление. плюшка форта - быть этаким ассемблером для стековой машины
Y
так я не понял, что в процессоре должно быть чтобы он назывался лисп-процессор ?
Аппаратные особые формы!
L
Переслано от Philippe Fominykh
нет, этож ленивый функционал, а лисп eager и императивный
MK
Привет, я Миша и я не знаю как использовать SQL базы.
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
AT
Привет, я Миша и я не знаю как использовать SQL базы.
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
Так-то да, создатели первых СУРБД не предполагали, что их будут использовать как сторадж для Веб-приложений... потому что никакого Веб вообще не было! 😂
AT
Привет, я Миша и я не знаю как использовать SQL базы.
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
Я хорошо знаком с ними наверное лет 10. Писал сложные запросы, оптимизировал их, оптимизировал хранение, чтобы туда влезало полтерабайта данных.
Я понимаю паттерны вроде Unit of work и Identity map.
Но блин, я не понимаю как правильно работать с БД. Такое ощущение, что мы как-то противоестественно их используем. Не так, как расчитывали их создатели.
Зачем мне в памяти держать копию данных, менять их и героически синхронизировать с состоянием транзакции.
Почему просто не сделать БД единственным источником правды?
Да, много запросов рождают задержки, но настолько ли это серьезно?
Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Может быть кто-нибудь видел книжку или доклад?
> Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Потому что HTTP — stateless протокол. Request-response — всё, конец разговора.
Application server лучше тоже держать stateless потому что балансировка нагрузки, failover и горизонтальное масштабирование.
Потому что HTTP — stateless протокол. Request-response — всё, конец разговора.
Application server лучше тоже держать stateless потому что балансировка нагрузки, failover и горизонтальное масштабирование.
MK
> Почему, когда контент-менеджер заполняет форму, нельзя отрыть транзакцию и постепенно записывать данные, получать идентификаторы создаваемых вложенных сущностей?
Потому что HTTP — stateless протокол. Request-response — всё, конец разговора.
Application server лучше тоже держать stateless потому что балансировка нагрузки, failover и горизонтальное масштабирование.
Потому что HTTP — stateless протокол. Request-response — всё, конец разговора.
Application server лучше тоже держать stateless потому что балансировка нагрузки, failover и горизонтальное масштабирование.
когда полтора человека в день редактируют сайт? Можно так-то и состояние держать и вебсокеты использовать. Или это еще сложнее и больнее?