Ясно. Честно говоря я слабо знаю Lisp. Как я понял: создаётся div и сразу после создания на сервер отправляется его clientHeight. Хорошо. А как запросить у броузера информацию Вы уже продумывали механизм?
Я лично у себя использую websocket-соединение чтоб общаться с броузером. Но он асинхронный. И это создаёт сложности. В данный момент я просто делаю wait в коде пока не придёт ответ от броузера. Других удобных способов я не нашёл пока-что.
Любопытная статья. Я примерно такое-же реализую, но для Smalltalk.
После создания элемента через OMG он храниться в каком-то серверной версии DOM-дерева? Или всё отправляется в броузер сразу? Как получить у созданного элемента свойство clientHeight/clientWidth через OMG? Надо посылать специальный запрос в броузер?
Как там с жильём, почём, где, на каких условиях? Как там с едой, почём и какая? Как с документами, оформление визы? Отношение индийцев к русским, когда узнают что из России? Хотелось бы вот это услышать)
Я редко пишу юнит-тесты, т.к. они достаточно хлопотны как для меня. Восновном я пишу тесты сразу на часть системы, на её фрагмент, тестирующие сразу несколько классов как одно целое. Такие тесты уже как бы и не юнит-тесты, но и интеграционными считаться могут только частично.
В отношении трудозатрат и эффективности у меня на практике получается очень выгодно: меньше мокать надо, меньше тестового кода и его отладки, больше обхват, дополнительный отладочный вывод опять жеш и т.п. И как-раз глобальная константа установленная в true во время запуска тестов и помогает временно отключить ненужные части системы и ускорить прохождение тестов. А поскольку я активно использую тесты во время отладки и добавления нового функционала (TDD) то скорость отработки тестов становиться очень важной.
Естественно тестмод отключается когда запускаются "главные тесты" тестирующие всю систему в комплексе.
Всё так, всё так) Только, лично я предпочитаю использовать минимум инструментов готовых и многие тесты пишу как самописные программы.
Ещё есть особенность, когда пишешь тесты сам для своего кода, то сам код начинаешь писать так, чтоб потом легче было тестировать и тесты писать под него. Даже специальную константу TEST_MODE приходиться вводить, чтоб тесты быстрее отрабатывались.
Почему-то сколько я читаю про программирование на естественных языках, никто не упоминает про существительные и глаголы, про прилагательные и наречия, про предлоги и т.д. И что глаголы являются главными в предложении и соответствуют функциям в программировании. А существительные и предложные части могут быть аргументами функции соответственно.
К тому-же простые предложения, по крайней мере в русском языке, имеют достаточно простую структуру: субъект(сущ.) действие(глагол) объект(сущ.) обстоятельство1 (предлог+...) обстоятельство2 (предлог+...) обстоятельствоN... И всё это достаточно просто парситься. Я когда делал свой первый алгоритм разбора рецепта горохового супа, заранее привёл рецепт к последовательности таких предложений и успешно распарсил. И это был алгоритм парсинга "в лоб". Т.е. последовательно слово за словом, строго по приведённому шаблону.
Потом конечно я начал усложнять алгоритм и добавил союзы "и" и "или" и всё как-то стало очень сложно. В лоб уже дальше не прокатывало)
Свалиться с ошибкой: Встречен неизвестный токен "по вкусу"!))) Шутка конечно.
Если серьёзно, то наверное полезит в специальный справочник, где указано для какой массы, объёма и с какими ингредиентами какое количество соли оптимальное. Потом поищет по истории сколько он клал в последний раз для этого конкретного человека в эти блюдо и какой был отзыв и примет оптимальное решение.
Я уже когда несколько лет назад писал первый алгоритм разбора и выполнения рецепта горохового супа встретил фразу "...откройте крышку и, если необходимо, снимите пенку" и это вызвало ряд глубоких раздумий. А потом ещё встретил "Немного измельчите суп в блендере, кухонном комбайне или воспользуйтесь толкушкой..." что уже было весьма расплывчато и непонятно как выполнять. Сейчас уже конечно я думаю, что специальные справочники помогут это успешно порешать, преодолеть. А так поначалу, это было конечно очень непонятно, что с этим делать)
Сомневаюсь, что у меня, в моей работе дневник окупит себя. У меня достаточно хорошая память, вроде её хватает.
Я лично на бумагу зарисовываю только структуры данных и наброски кода. Последние ещё делать относительно несложно, а вот первые весьма геморно. Но надо делать. Потому, что 20 летний программистский опыт показал, что надо делать сначала карандашом на бумаге, а потом садиться за компьютер. Так эффективнее всего выходит. Можно это делать и в голове, но делать надо обязательно перед)
Да смысл выкладывать. Я уже третий вариант делаю. 1ый так и лежит поломанный на javascript. Второй уже делался частично на php, частично на smalltalk. Третий текущий уже полностью на smalltalk-e. Критиковать там много что есть: код сложный и не оформленный, очень много костылей. Это же наука. Тут главное провести эксперимент, получить результат, ценную информацию, а потом всё это можно выкинуть в мусорку)
Да, вобщем-то так оно и вырисовывается сейчас. Я работаю над разборкой и выполнением кулинарных рецептов сейчас. Точнее над рецептом приготовления горохового супа. Но на разных языках: русском, английском, испанском, немецком. И уже много кулинарно-специфических вещей всплыло)
Но я верю, что есть нечто универсальное, базовое во всех сферах, предметных областях или доменах как Вы их называете. И после того, как я это выведу, дальше станет легче.
Я лично работаю над возможностью писать программы на родном языке вместо специальных компьютерный языков программирования уже несколько лет. И считаю, что это вполне возможно.
Сейчас я вижу, что для успешного разбора алгоритма, т.е. последовательности действий на человеческом языке требуется от системы понимать сложившуюся ситуацию, какие действия что делают и к чему приводят и, вообще, как устроен мир вокруг. Большинство текущих компиляторов и интерпретаторов не понимают ни контекст, ни смысл. А требуют чтоб программист сам указывал всё, что нужно для успешного выполнения каждого действия.
Нет. Мне тяжело было его учить и я отказался от изучения этого языка.
Наверное потому, что в школе с грамматикой родного русского языка у меня не сложилось. Или по простому: я был двоишником по русскому языку)
Т.е. базовых познаний по грамматике у меня не было вообще в начале изучения Ложбана.
… нюансами четкой логики.
Мысли сами по себе были не чёткие, а ещё их надо было чётко выражать — и это было самое трудное при моих попытках что-либо выразить на ложбане. Довольствовался только примерным объяснением того, что хочу сказать. При этом ещё и словарь скудный в ложбане. А образовывать lujvo я опасался тем, что меня вообще поймут совсем по другому.
У меня нет опыта программирования на ClojureScript.
Но те примеры, которые я видел, смотрятся приятно на мой взгляд.
Например, я недавно добавил экспериментальную поддержку макросов и вместе с модификатором "," добавил альтернативный вариант с "~", который я видел в ClojureScript.
Вы начинаете общаться грубо и мне это не приятно. К тому же, Ваш ответ это начало того, что я называю "срачь". Чего я не люблю. Я не хочу продолжать с Вами общение. Простите.
Наверное я не правильно написал. Я имел ввиду звучат как в английском или наверное точнее как в латинском.
gentleman — будет читаться как "гэнтлэман"
language — будет читаться как "лангуагэ".
"garage" — будет читаться как "гарагэ"
Я молчу потому, что я разочарован, что мои разработки были приняты столь негативно и мои комментарии минусуют. Это мой первый проект вынесенный на публичное рассмотрение. Сейчас я несколько охладел к Lisp-у.
Если-бы написали конструктивные рекомендации что и как стоит добавить, яб с радостью это обсудил бы. И добавил бы если это возможно.
Не надо ругаться коллеги-программисты:)
Еслиб я заранее знал про макросы и многие другие особенности Lisp-a яб не брался за этот проект. Меня привлекла простота Lisp-а на поверхностный взгляд. Сейчас я вижу, что он сложнее чем Smalltalk:(
У меня основной упор был сделан на создание хорошего дебаггера. По этому парсер и интерпретатор были полностью переписаны. И от старого проекта осталось только часть описания Context, пара строк сначала и несколько строк в конце скрипта littlelisp.js. Ну и название частично.
Вобщем-то, весь старый оригинальный функционал был удалён.
В любом случае я признателен Mary Rose Cook за её реализацию Lisp-a. Считаю, что её реализация замечательна и прекрасно. Это меня и вдохновило форкнуть и расширить функционал.
Но пришлось всё переписать по своему чтоб внедрить дебаггинг. И от её красоты, к сожалению, ничего не сохранилось :(
В 1.0beta3 я добавил tail-call optimization для экономии оперативной памяти. Теперь обнаруживается хвостовая рекурсию и переиспользуется текущий контекст функции.
С макросами пока-что тяжело идёт дело, к сожалению. Не могу обещать сроков.
У меня Stack overflow не может произойти. Т.к. нету стека вызовов. Используется цепочка контекстов и бесконечный цикл. Т.е. будет работать столько, сколько есть оперативной памяти (миллиард вызовов или более...).
Я добавил в beta3 TCO.
Пожалуйста не ссортись:)
Если есть конструктивные предложения, то скажите. Я постараюсь реализовать их по мере возможности.
Скажите пожалуйста, у вас есть опыт работы с отечественными имплантами? На фоне санкций и импортозамещения эта тема стала любопытна)
Так-же у вас был опыт с пациентами у которых во рту импланты разных производителей?
Ясно.
Честно говоря я слабо знаю Lisp.
Как я понял: создаётся div и сразу после создания на сервер отправляется его clientHeight.
Хорошо. А как запросить у броузера информацию Вы уже продумывали механизм?
Я лично у себя использую websocket-соединение чтоб общаться с броузером. Но он асинхронный. И это создаёт сложности. В данный момент я просто делаю wait в коде пока не придёт ответ от броузера. Других удобных способов я не нашёл пока-что.
Любопытная статья. Я примерно такое-же реализую, но для Smalltalk.
После создания элемента через OMG он храниться в каком-то серверной версии DOM-дерева? Или всё отправляется в броузер сразу? Как получить у созданного элемента свойство clientHeight/clientWidth через OMG? Надо посылать специальный запрос в броузер?
Как-то маловато информации)
Как там с жильём, почём, где, на каких условиях? Как там с едой, почём и какая? Как с документами, оформление визы? Отношение индийцев к русским, когда узнают что из России? Хотелось бы вот это услышать)
Ну что поделать, для Вас звучит, для меня нет)
Я редко пишу юнит-тесты, т.к. они достаточно хлопотны как для меня. Восновном я пишу тесты сразу на часть системы, на её фрагмент, тестирующие сразу несколько классов как одно целое. Такие тесты уже как бы и не юнит-тесты, но и интеграционными считаться могут только частично.
В отношении трудозатрат и эффективности у меня на практике получается очень выгодно: меньше мокать надо, меньше тестового кода и его отладки, больше обхват, дополнительный отладочный вывод опять жеш и т.п. И как-раз глобальная константа установленная в true во время запуска тестов и помогает временно отключить ненужные части системы и ускорить прохождение тестов. А поскольку я активно использую тесты во время отладки и добавления нового функционала (TDD) то скорость отработки тестов становиться очень важной.
Естественно тестмод отключается когда запускаются "главные тесты" тестирующие всю систему в комплексе.
Всё так, всё так)
Только, лично я предпочитаю использовать минимум инструментов готовых и многие тесты пишу как самописные программы.
Ещё есть особенность, когда пишешь тесты сам для своего кода, то сам код начинаешь писать так, чтоб потом легче было тестировать и тесты писать под него. Даже специальную константу TEST_MODE приходиться вводить, чтоб тесты быстрее отрабатывались.
Почему-то сколько я читаю про программирование на естественных языках, никто не упоминает про существительные и глаголы, про прилагательные и наречия, про предлоги и т.д. И что глаголы являются главными в предложении и соответствуют функциям в программировании. А существительные и предложные части могут быть аргументами функции соответственно.
К тому-же простые предложения, по крайней мере в русском языке, имеют достаточно простую структуру: субъект(сущ.) действие(глагол) объект(сущ.) обстоятельство1 (предлог+...) обстоятельство2 (предлог+...) обстоятельствоN... И всё это достаточно просто парситься. Я когда делал свой первый алгоритм разбора рецепта горохового супа, заранее привёл рецепт к последовательности таких предложений и успешно распарсил. И это был алгоритм парсинга "в лоб". Т.е. последовательно слово за словом, строго по приведённому шаблону.
Потом конечно я начал усложнять алгоритм и добавил союзы "и" и "или" и всё как-то стало очень сложно. В лоб уже дальше не прокатывало)
Свалиться с ошибкой: Встречен неизвестный токен "по вкусу"!)))
Шутка конечно.
Если серьёзно, то наверное полезит в специальный справочник, где указано для какой массы, объёма и с какими ингредиентами какое количество соли оптимальное. Потом поищет по истории сколько он клал в последний раз для этого конкретного человека в эти блюдо и какой был отзыв и примет оптимальное решение.
Я уже когда несколько лет назад писал первый алгоритм разбора и выполнения рецепта горохового супа встретил фразу "...откройте крышку и, если необходимо, снимите пенку" и это вызвало ряд глубоких раздумий. А потом ещё встретил "Немного измельчите суп в блендере, кухонном комбайне или воспользуйтесь толкушкой..." что уже было весьма расплывчато и непонятно как выполнять. Сейчас уже конечно я думаю, что специальные справочники помогут это успешно порешать, преодолеть. А так поначалу, это было конечно очень непонятно, что с этим делать)
Сомневаюсь, что у меня, в моей работе дневник окупит себя. У меня достаточно хорошая память, вроде её хватает.
Я лично на бумагу зарисовываю только структуры данных и наброски кода. Последние ещё делать относительно несложно, а вот первые весьма геморно. Но надо делать. Потому, что 20 летний программистский опыт показал, что надо делать сначала карандашом на бумаге, а потом садиться за компьютер. Так эффективнее всего выходит. Можно это делать и в голове, но делать надо обязательно перед)
Да смысл выкладывать. Я уже третий вариант делаю. 1ый так и лежит поломанный на javascript. Второй уже делался частично на php, частично на smalltalk. Третий текущий уже полностью на smalltalk-e. Критиковать там много что есть: код сложный и не оформленный, очень много костылей. Это же наука. Тут главное провести эксперимент, получить результат, ценную информацию, а потом всё это можно выкинуть в мусорку)
Да, вобщем-то так оно и вырисовывается сейчас. Я работаю над разборкой и выполнением кулинарных рецептов сейчас. Точнее над рецептом приготовления горохового супа. Но на разных языках: русском, английском, испанском, немецком. И уже много кулинарно-специфических вещей всплыло)
Но я верю, что есть нечто универсальное, базовое во всех сферах, предметных областях или доменах как Вы их называете. И после того, как я это выведу, дальше станет легче.
Я лично работаю над возможностью писать программы на родном языке вместо специальных компьютерный языков программирования уже несколько лет. И считаю, что это вполне возможно.
Сейчас я вижу, что для успешного разбора алгоритма, т.е. последовательности действий на человеческом языке требуется от системы понимать сложившуюся ситуацию, какие действия что делают и к чему приводят и, вообще, как устроен мир вокруг. Большинство текущих компиляторов и интерпретаторов не понимают ни контекст, ни смысл. А требуют чтоб программист сам указывал всё, что нужно для успешного выполнения каждого действия.
Нет. Мне тяжело было его учить и я отказался от изучения этого языка.
Наверное потому, что в школе с грамматикой родного русского языка у меня не сложилось. Или по простому: я был двоишником по русскому языку)
Т.е. базовых познаний по грамматике у меня не было вообще в начале изучения Ложбана.
Мысли сами по себе были не чёткие, а ещё их надо было чётко выражать — и это было самое трудное при моих попытках что-либо выразить на ложбане. Довольствовался только примерным объяснением того, что хочу сказать. При этом ещё и словарь скудный в ложбане. А образовывать lujvo я опасался тем, что меня вообще поймут совсем по другому.
У меня нет опыта программирования на ClojureScript.
Но те примеры, которые я видел, смотрятся приятно на мой взгляд.
Например, я недавно добавил экспериментальную поддержку макросов и вместе с модификатором "," добавил альтернативный вариант с "~", который я видел в ClojureScript.
Вы начинаете общаться грубо и мне это не приятно. К тому же, Ваш ответ это начало того, что я называю "срачь". Чего я не люблю. Я не хочу продолжать с Вами общение. Простите.
Наверное я не правильно написал. Я имел ввиду звучат как в английском или наверное точнее как в латинском.
gentleman — будет читаться как "гэнтлэман"
language — будет читаться как "лангуагэ".
"garage" — будет читаться как "гарагэ"
Я добавил список уже переведённой литературы в конец статьи.
Я тоже, честно говоря, на первых шагах хотел сделать переводчик Ложбан->Русский, хотя бы по словесный. Но руки так и не дошли...
У Ложбана — да, мелодичность не очень. У Логланга с этим лучше.
g — читается как Г (как в слове get)
j — читается как Ж (как в слове jasmin)
По этому gif — читается как "гиф". А jpeg — читается как "жпег".
Я молчу потому, что я разочарован, что мои разработки были приняты столь негативно и мои комментарии минусуют. Это мой первый проект вынесенный на публичное рассмотрение. Сейчас я несколько охладел к Lisp-у.
Если-бы написали конструктивные рекомендации что и как стоит добавить, яб с радостью это обсудил бы. И добавил бы если это возможно.
Не надо ругаться коллеги-программисты:)
Еслиб я заранее знал про макросы и многие другие особенности Lisp-a яб не брался за этот проект. Меня привлекла простота Lisp-а на поверхностный взгляд. Сейчас я вижу, что он сложнее чем Smalltalk:(
У меня основной упор был сделан на создание хорошего дебаггера. По этому парсер и интерпретатор были полностью переписаны. И от старого проекта осталось только часть описания Context, пара строк сначала и несколько строк в конце скрипта littlelisp.js. Ну и название частично.
Вобщем-то, весь старый оригинальный функционал был удалён.
В любом случае я признателен Mary Rose Cook за её реализацию Lisp-a. Считаю, что её реализация замечательна и прекрасно. Это меня и вдохновило форкнуть и расширить функционал.
Но пришлось всё переписать по своему чтоб внедрить дебаггинг. И от её красоты, к сожалению, ничего не сохранилось :(
В 1.0beta3 я добавил tail-call optimization для экономии оперативной памяти. Теперь обнаруживается хвостовая рекурсию и переиспользуется текущий контекст функции.
С макросами пока-что тяжело идёт дело, к сожалению. Не могу обещать сроков.
У меня Stack overflow не может произойти. Т.к. нету стека вызовов. Используется цепочка контекстов и бесконечный цикл. Т.е. будет работать столько, сколько есть оперативной памяти (миллиард вызовов или более...).
Я добавил в beta3 TCO.
Пожалуйста не ссортись:)
Если есть конструктивные предложения, то скажите. Я постараюсь реализовать их по мере возможности.