All streams
Search
Write a publication
Pull to refresh
15
0

Программист

Send message

Я лично работаю над возможностью писать программы на родном языке вместо специальных компьютерный языков программирования уже несколько лет. И считаю, что это вполне возможно.

Сейчас я вижу, что для успешного разбора алгоритма, т.е. последовательности действий на человеческом языке требуется от системы понимать сложившуюся ситуацию, какие действия что делают и к чему приводят и, вообще, как устроен мир вокруг. Большинство текущих компиляторов и интерпретаторов не понимают ни контекст, ни смысл. А требуют чтоб программист сам указывал всё, что нужно для успешного выполнения каждого действия.

Нет. Мне тяжело было его учить и я отказался от изучения этого языка.


Наверное потому, что в школе с грамматикой родного русского языка у меня не сложилось. Или по простому: я был двоишником по русскому языку)
Т.е. базовых познаний по грамматике у меня не было вообще в начале изучения Ложбана.


… нюансами четкой логики.

Мысли сами по себе были не чёткие, а ещё их надо было чётко выражать — и это было самое трудное при моих попытках что-либо выразить на ложбане. Довольствовался только примерным объяснением того, что хочу сказать. При этом ещё и словарь скудный в ложбане. А образовывать 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.
Пожалуйста не ссортись:)
Если есть конструктивные предложения, то скажите. Я постараюсь реализовать их по мере возможности.

Лично я писал систему для отслеживания цен и обмена данными (товарами, ценами и заказами) между 1C и сайтом. Несколько лет поддерживал. Работало более-менее нормально. Делалось на Cincom VisualWorks Smalltalk 7.4.
А так программирую на нём уже 13 лет и буду дальше программить)
У него великолепный дебаггер. В 2 раза ускоряет мне разработку/программирование. Но язык, на мой взгляд, средненький.

Я хочу про IDE рассказать, но она не достаточно отчищена от багов. А глючная IDE это весьма неудобно)
Я пока-что оптимизацию хвостовой рекурсии отлаживаю. А там ещё над макросами надо думать...

Макросы будут, когда я пойму как их "подружить" с JavaScript. Не так всё просто к сожалению с ними(

Я когда работал в одной региональной веб-студии, к нам приезжал один мужик из Москвы, директор столичной веб-студии размером в 50 человек. И на встрече обмена опытном сказал, что он за 10 лет работы встречал только 2 сеньёров девелоперов(!). Мне показалось это очень странным для Москвы, и за 10 лет...

Почитал статью по ссылке. Любопытненько.
От скобочек действительно было бы выгодно отказаться. Правда это уже был бы не Лисп, я думаю))


setq i 0 id null
while 
    < i sentence1.length
    setq prev_id id
    setq id 
            Storage.set 
                 + "string" 
                      Brain.new_id
                 :type 
                 "word" 
                 :value 
                 sentence1.@i 
                 :prev_id
                 prev_id
    if 
            != prev_id null
            Storage.set 
                 prev_id 
                 :next id
    ++ i

Не уверен, что читабельность увеличилась...

Вообще немного коробит)
Но честно говоря форма (+ x y z) меня коробит побольше. Lisp для меня пока-что новый язык.
Возможно я добавлю такой синтаксис тоже в парсер. Хотя у меня были идеи сделать более сложный механизм арифметики. Например (x + y * z — a) парсилось бы в (+*- x y z a) и интерпретатором вычислялось бы отдельно каждая операция. Т.е. сначала "+", потом "*" и потом "-". Мне кажется это выгоднее было-бы.
Честно говоря я не встретил случаев когда нужна быль хвостовая рекурсия и соответственно её оптимизация в интерпретаторе. Я предполагаю это из-за того что есть while. Без него циклы пришлось бы организовывать рекурсией.
В Erlang нету циклов. Там надо использовать хвостовую рекурсию для организации цикличности. Но там green threads и это как раз выгодно для их функционирования.
Нет, не я. А что за ведущий?)

Information

Rating
Does not participate
Location
Краснодар, Краснодарский край, Россия
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Web Developer
Senior
OOP
Java
Python
PHP
Git
SQL
REST