Re[4]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 05:00
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, batu, Вы писали:


M>>>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...

B>>Если точного определения сложности нет, то почему бы не допустить что это так? Тем более дальнейшие рассуждения вполне заслуживают интерес. Относись как к гипотезе.

IT>Можно даже как к эзотерическому учению Главное, что есть модель, которая работает. Может быть не для всех, может быть не всегда, но в большинстве случаев вполне сносно объясняет суть происходящего. Когда учоные создадут более адекватную модель и опишут сложность универсальными формулами и метриками, то на эту теорию можно будет смело забить. Я сделаю это первый, если доживу

Такова судьба любой теории.
Re[13]: Закон сохранения сложности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.09.10 06:39
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:


IT>>>Постфактум мало интересен. Мне нужно принимать решение здесь и сейчас, а не после разбора полётов.

G>>Анализ предыдущего опыта (не только своего) помогает принимать решения.

IT>Опыт вообще-то как раз из области метафизика, как говорит уважаемый Гапертон. Да и помогает он только не делать ошибок, которые уже были сделаны ранее, т.е. осечь заведомо плохие варианты. Найти наиболее оптимальное решение в совершенно новой ситуации он не помогает.


Ну так поробуй формализовать понятия "не делать ошибок" и "заведомо плохие варианты", получишь те самые метрики.
Любое планирование будет метафизикой если не использовать метрики.
Re[16]: Закон сохранения сложности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.09.10 06:47
Оценка:
Здравствуйте, batu, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:


G>>Здравствуйте, batu, Вы писали:


B>>>А в том, что грамматику можно и нужно определить (и постороить компилятор) для любых объектов, а не только для букв (которые сейчас и не объекты.. а что-то левое, заданное где-то и кем-то сверху).

G>>Я прочитал много твоих постов. Могу дать одну рекомендацию: когда хочешь написать слово объект, не пиши его, а попробуй заменить на более подходящее слово в этом контексте.
B>Были обсуждения по этому поводу. Предлагались фреймы, монады. Не то. Все-таки к объекту это ближе. А сочинять что-то новое тоже не вариант.

Не надо сочинять, почти в любом разговоре ты используешь слово "объект" вместо какого-то устоявшегося понятия, при этом сбивая не только собеседника, но и себя.

G>>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого.

B>Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем.
Более высоким уровнем чего?

B>Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики.

Взаимоисключающие фразы. Называя все объектами ты усложняешь понимание другим людям, которые как минимум понимают что такое формальные грамматики.

B>Понятия терминальные и нетерминальные символы убрать. Оставить правила (предикаты), имена которых непосредственно определяют лексему и продукцию.

Получишь peg.

B>Эти имена тогда будут формулироваться в терминах создаваемого языка, что опять таки будет семантически ближе пользователю. Напрямую в общем случае это не получается. Иногда возникает необходимость в промежуточных (вспомогательных) правилах не создающих ни лексему ни продукцию. Ну, и у меня получилось так сделать. Т.е. построение грамматики стало возможно в общей концепции языка. Не надо никаких регекспов и вводить новые понятия. Вот туда я и веду. И с теорией противоречия нет. Фактически те же алгоритмы восходящий для лексики и нисходящий для синтаксиса. Просто другое представление. Я бы сравнил с машиной Тьюринга. Вещь хорошая для доказательств, но для реального создания программ мало подходящая. Так и теорию грамматик. Вещь хорошая, но для широкого использования надо бы формулировать в терминах ООП. Что я и пытаюсь сделать.

Я вот понимаю слова по отдельности, а общего смысла не понимаю.

Здесь вообще-то другая тема обсуждается. Ты в своей теме про язык приведи работающий пример и докажи формально что он эквивалентен какой-либо грамматике с этими самыми терминальными и нетерминальными символами. Например разбор арифметического выражения с учетом ассоциативности и приоритетов.
Re[17]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 10:26
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, batu, Вы писали:


G>Не надо сочинять, почти в любом разговоре ты используешь слово "объект" вместо какого-то устоявшегося понятия, при этом сбивая не только собеседника, но и себя.

Почему "вместо"? Понимай как понимаешь. Какие проблемы? В С-ях же не путает. И в джаве не путает. Хотя там сообщений нет, как в смолтоке.

G>>>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого.

B>>Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем.
G>Более высоким уровнем чего?
Сформулируй вопрос. Я не понял.

B>>Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики.

G>Взаимоисключающие фразы. Называя все объектами ты усложняешь понимание другим людям, которые как минимум понимают что такое формальные грамматики.
Нет ничего взаимоисключающего. Как и слово "дифференциал" не усложняет "отношение приращения функции к приращению аргумента". Чем удобней пользоваться?

B>>Понятия терминальные и нетерминальные символы убрать. Оставить правила (предикаты), имена которых непосредственно определяют лексему и продукцию.

G>Получишь peg.
Почти.

B>>Эти имена тогда будут формулироваться в терминах создаваемого языка, что опять таки будет семантически ближе пользователю. Напрямую в общем случае это не получается. Иногда возникает необходимость в промежуточных (вспомогательных) правилах не создающих ни лексему ни продукцию. Ну, и у меня получилось так сделать. Т.е. построение грамматики стало возможно в общей концепции языка. Не надо никаких регекспов и вводить новые понятия. Вот туда я и веду. И с теорией противоречия нет. Фактически те же алгоритмы восходящий для лексики и нисходящий для синтаксиса. Просто другое представление. Я бы сравнил с машиной Тьюринга. Вещь хорошая для доказательств, но для реального создания программ мало подходящая. Так и теорию грамматик. Вещь хорошая, но для широкого использования надо бы формулировать в терминах ООП. Что я и пытаюсь сделать.

G>Я вот понимаю слова по отдельности, а общего смысла не понимаю.
Вот тут я не знаю чем помочь. Могу повторить.

G>Здесь вообще-то другая тема обсуждается. Ты в своей теме про язык приведи работающий пример и докажи формально что он эквивалентен какой-либо грамматике с этими самыми терминальными и нетерминальными символами.

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

Например разбор арифметического выражения с учетом ассоциативности и приоритетов.
Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно.
Re[18]: Закон сохранения сложности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.09.10 11:27
Оценка:
Здравствуйте, batu, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:


G>>Здравствуйте, batu, Вы писали:


G>>Не надо сочинять, почти в любом разговоре ты используешь слово "объект" вместо какого-то устоявшегося понятия, при этом сбивая не только собеседника, но и себя.

B>Почему "вместо"? Понимай как понимаешь. Какие проблемы? В С-ях же не путает. И в джаве не путает. Хотя там сообщений нет, как в смолтоке.
Вызов метода — частный случай отправки сообщения.

G>>>>Если что любая грамматика определяется над некоторым алфавитом терминальных и нетерминальных символов. Что есть символы теория не говорит. В принципе это неважно, главное чтобы был способ отличить один от другого.

B>>>Да. Это так. Может я не могу сформулировать. Но ход мысли такой. Я хочу оперировать более высоким уровнем.
G>>Более высоким уровнем чего?
B>Сформулируй вопрос. Я не понял.
Ты хочешь оперировать более высоким уровнем чего?

B>>>Что б в анализе участвовали объекты. Что бы пользователю было легче ориентироваться и создавать свои грамматики.

G>>Взаимоисключающие фразы. Называя все объектами ты усложняешь понимание другим людям, которые как минимум понимают что такое формальные грамматики.
B>Нет ничего взаимоисключающего. Как и слово "дифференциал" не усложняет "отношение приращения функции к приращению аргумента". Чем удобней пользоваться?
Еще раз: называя все объектами ты усложняешь понимание. Это хорошо видно в твоей теме с языком.


B> Например разбор арифметического выражения с учетом ассоциативности и приоритетов.

B>Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно.
Ассоциативность — свойство операторов, а не разбора.

Как разбирать выражение
a / b / c

?

Два варианта:

(a/b) / c

a / (b/c)


Это называется левой и правой ассоциативностью операторов.

Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то).
Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
Re[19]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 12:37
Оценка: :)
Здравствуйте, gandjustas, Вы писали:


B>>Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно.

G>Ассоциативность — свойство операторов, а не разбора.

G>Как разбирать выражение

G>
G>a / b / c
G>

G>?

G>Два варианта:


G>
G>(a/b) / c

G>a / (b/c)
G>


G>Это называется левой и правой ассоциативностью операторов.


G>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то).

G>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему. Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно..
Re[20]: Закон сохранения сложности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.09.10 12:45
Оценка:
Здравствуйте, batu, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:



B>>>Разбор выражения есть, конечно. С учетом приоритета. А вот насчет ассоциативности мне она не понадобилась. Есть она или нет, моему алгоритму все равно. Покажи как используется ассоциативность при разборе выражений. Интересно.

G>>Ассоциативность — свойство операторов, а не разбора.

G>>Как разбирать выражение

G>>
G>>a / b / c
G>>

G>>?

G>>Два варианта:


G>>
G>>(a/b) / c

G>>a / (b/c)
G>>


G>>Это называется левой и правой ассоциативностью операторов.


G>>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то).

G>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
B>А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему.
Ну так как он разберет выражение a / b / c? И почему именно так, а не по-другому?

B>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно..

Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил.

Ты говоришь что что твое описание парсера эквивалентно некоторой формальной грамматике в виде peg или bnf.
Вот и напиши свою грамматику в таком виде, а все твои рассуждения об объектах и новых концепциях никому не нужны.
Re[21]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 13:05
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>>>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то).

G>>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
B>>А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему.
G>Ну так как он разберет выражение a / b / c? И почему именно так, а не по-другому?
Да так и разберет. Подряд. Как равно приоритетные. А когда нужно по другому?

B>>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно..

G>Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил.
Да все понятно. Не понятна только практическая необходимость. Вот выражение разбирается так. Если программисту нужна другая последовательность выполнения каких-то специфических правоассоциативных операций, то пусть скобки пишет.

G>Ты говоришь что что твое описание парсера эквивалентно некоторой формальной грамматике в виде peg или bnf.

G>Вот и напиши свою грамматику в таком виде, а все твои рассуждения об объектах и новых концепциях никому не нужны.
Разумно.
Re[22]: Закон сохранения сложности
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 22.09.10 13:07
Оценка:
Здравствуйте, batu, Вы писали:

Бату, я там задавал вопрос выше на счет компилятора. Есть ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[22]: Закон сохранения сложности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.09.10 13:15
Оценка:
Здравствуйте, batu, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:



G>>>>Еще могут быть неассоциативные операторы, для которых необходимо явно указывать порядок (скобками или еще как-то).

G>>>>Все генераторы парсеров учитывают ассоциативность, что в этом случае делает твой?
B>>>А мой не учитывает. Как написано програмистом, так и разбирает. Даже не думал на эту тему.
G>>Ну так как он разберет выражение a / b / c? И почему именно так, а не по-другому?
B>Да так и разберет. Подряд. Как равно приоритетные. А когда нужно по другому?
Когда есть правоассоциативные операторы, например a=b=c.

B>>>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно..

G>>Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил.
B>Да все понятно. Не понятна только практическая необходимость. Вот выражение разбирается так. Если программисту нужна другая последовательность выполнения каких-то специфических правоассоциативных операций, то пусть скобки пишет.

Ты уже сливаешь. Пора бы признать что твой мега-парсер с объектами таки не все умеет, а ты еще неочень опытен в построении языков.
Re[23]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 13:27
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, batu, Вы писали:


PC_>Бату, я там задавал вопрос выше на счет компилятора. Есть ?

ТLL есть. Lada нет. Начал писать. Отвлекают всякие дела. Где-то через пару месяцев будет. Да и вот видишь обсуждаем. Тоже нужное дело. А я разве не ответил тогда? У меня этот месяц в трубу ушел.
Re[24]: Закон сохранения сложности
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 22.09.10 13:33
Оценка:
Здравствуйте, batu, Вы писали:

B>Здравствуйте, PC_2, Вы писали:


PC_>>Здравствуйте, batu, Вы писали:


PC_>>Бату, я там задавал вопрос выше на счет компилятора. Есть ?

B>ТLL есть. Lada нет. Начал писать. Отвлекают всякие дела. Где-то через пару месяцев будет. Да и вот видишь обсуждаем. Тоже нужное дело. А я разве не ответил тогда? У меня этот месяц в трубу ушел.

я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое.
язык С#.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[23]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 13:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, batu, Вы писали:



B>>>>Но, вопрос даже не в том. Если определять операции пользовательские, то тогда кроме приоритета надо еще и ассоциативность где-то указывать... Практически где это нужно? Сделать то все можно..

G>>>Для в любом языке с выражениями это нужно. Выражение a / b / c является верным для большинства ныне существующих языков, и каждый из них определяет ассоциативность и приоритет операций. А если ты не определяешь, значит где-то схалтурил.
B>>Да все понятно. Не понятна только практическая необходимость. Вот выражение разбирается так. Если программисту нужна другая последовательность выполнения каких-то специфических правоассоциативных операций, то пусть скобки пишет.
G>
G>Ты уже сливаешь. Пора бы признать что твой мега-парсер с объектами таки не все умеет, а ты еще неочень опытен в построении языков.
Как же я солью если есть правоассоциативные операторы, например a=b=c.
Кстати, мега-парсер это не я придумал.. Зачем обзываешься? И еще. Не стыдно не знать. Стыдно не хотеть знать. Так что я по любому благодарен за общение. Я ж не в институте и не на фирме. Сам себе дома работаю. Оппонентов и помошников нет. Только книги и инет.
По операциям еще будет повод пообзываться.. Вот сформулирую и напишу. Вволю поотрываетесь.
Re[25]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 13:40
Оценка: :)
Здравствуйте, PC_2, Вы писали:



PC_>я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое.

PC_>язык С#.
Переведи на русский. Я ж сказал что работаю сам. Потому с терминологией принятой не очень знаком. Иногда угадываю иногда нет. Что такое подсветка? Сотрудничеству всегда рад.
Re[26]: Закон сохранения сложности
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 22.09.10 13:43
Оценка:
Здравствуйте, batu, Вы писали:

B>Здравствуйте, PC_2, Вы писали:




PC_>>я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое.

PC_>>язык С#.
B>Переведи на русский. Я ж сказал что работаю сам. Потому с терминологией принятой не очень знаком. Иногда угадываю иногда нет. Что такое подсветка? Сотрудничеству всегда рад.

Подсветка это выделение ключевых слов и конструкций в твоем языке другим цветом.
Обычно ключевые слова подсвечиваются синеньким, а строки красным. Но зависит в какой студии ты работаешь
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[27]: Закон сохранения сложности
От: batu Украина  
Дата: 22.09.10 13:50
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, batu, Вы писали:


B>>Здравствуйте, PC_2, Вы писали:




PC_>>>я чего спросил, можно например скооперироваться, могу докрутить твой язык в студию, взамен нужна помощь докрутить нормально визуальный контрол. Подсветка и все такое.

PC_>>>язык С#.
B>>Переведи на русский. Я ж сказал что работаю сам. Потому с терминологией принятой не очень знаком. Иногда угадываю иногда нет. Что такое подсветка? Сотрудничеству всегда рад.

PC_>Подсветка это выделение ключевых слов и конструкций в твоем языке другим цветом.

PC_>Обычно ключевые слова подсвечиваются синеньким, а строки красным. Но зависит в какой студии ты работаешь
Фигня вопрос. Даже не вопрос. Осталось наладить связь. А ты работаешь где? Или в чем интерес?
У меня с неделю будут проблемы. Переразметил нечаянно винт, с проектом. А он террабайтный. Надо купить новый и восстановить данные. Проверил они целые. Только у меня старый Getback. Там только по одному файлу можно вытаскивать..Надо найти чем восстановить..Там и прога, и документация..Вообщем все..
Re[10]: Закон сохранения сложности
От: Silver_s Ниоткуда  
Дата: 22.09.10 13:54
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>Ты откуда планирование загруженности взял?
Там было про график работ, распределение задач, оценку производительности, управление сроками.
А если это все неактуально, а нужно в первую очередь узнать нужно ли вобще такую-то задачу решать, или лучше совсем другую.
Почему LINQ for SQL не оправдал ожиданий MS (судя по всему ожидания были гораздо выше)? Наверно не из-за того что не смогли вовремя индуса вычислить который выпал из среднеквадратического отклонения по числу багов. И не из-за того что неправильно определили сроки. На пути образовался тупик, которого не было сразу видно.

G>Давай так. Лично ты на основании чего будешь делать выбор WinForms или WPF?

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

У WPF возможности не безграничны, и недостатков немало. Многие недостатки типичны для frameworks которые много на себя берут — когда надо делать все в жестких рамках, только то для чего оно приспособлено, тогда все как по рельсам гладко. А чуть шаг в сторону попадешь в болто.
Да и еще надо учитывать что WPF на словах это аппаратное ускорение графики, а на деле чаще аппаратное замедление.
Рисует он гораздо медленнее GDI+, но Zoom, и градиенты быстрее делает.
И вобше впрос интересный стоило ли тащить WPF на D3D устройство, увеличило ли это скорость или уменьшило.
D3D ведь тоже не сахар, и не все он делает быстро. 50 микро секунд весь цикл рисования одного маленького обьекта. Cколько за это время нарисуешь обьектов на GDI+ и не сосчитаешь. Зато D3D может обрабатывать объекты пачками, но на эти пачки объектов жесткие ограничения в которых GUI очень тесно. GUI все-таки штука посложнее чем 3D сцены в игрушках.
Пляски с бубном вокруг этого D3D и приводят к тому что сам D3D выполняет работу быстро, а для процессора получается работы еще больше чем в рисовании на GDI+.
в этом месте засада, для тех кто посмотрит спецификации видеокарточки, сколько треугольников в секунду перемалывает, и начнет потирать руки подсчитав как у него шустро должен работать WPF.
Re[28]: Закон сохранения сложности
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 22.09.10 13:59
Оценка:
Здравствуйте, batu, Вы писали:

B>Фигня вопрос. Даже не вопрос. Осталось наладить связь. А ты работаешь где? Или в чем интерес?


я в Киеве. На .NET работаю.
Интерес развивать идеи Ресерч Студио с отладкой на графах и нужны ребята в проект
Поэтому когда ты допишешь свой компилятор, помогу прикрутить тебе отладку двух типов, разные окошки и профайлеры. Главное чтобы был парсер и компилятор готовый на твой язык.
Взамен нужно будет потихоньку тратить время и на студию, фиксить там баги и дорабатывать все что поможет тебе лучше писать на твоем языке в новой Ресерч Студии.

Связаться можно со мной будет на этом форуме или по почте tuz.vyacheslav@gmail.com
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[29]: Закон сохранения сложности
От: Курилка Россия http://kirya.narod.ru/
Дата: 22.09.10 14:00
Оценка: :)
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, batu, Вы писали:


B>>Фигня вопрос. Даже не вопрос. Осталось наладить связь. А ты работаешь где? Или в чем интерес?


PC_>я в Киеве. На .NET работаю.

PC_>Интерес развивать идеи Ресерч Студио с отладкой на графах и нужны ребята в проект
PC_>Поэтому когда ты допишешь свой компилятор, помогу прикрутить тебе отладку двух типов, разные окошки и профайлеры. Главное чтобы был парсер и компилятор готовый на твой язык.
PC_>Взамен нужно будет потихоньку тратить время и на студию, фиксить там баги и дорабатывать все что поможет тебе лучше писать на твоем языке в новой Ресерч Студии.

PC_>Связаться можно со мной будет на этом форуме или по почте tuz.vyacheslav@gmail.com


Извиняюсь, что встреваю, но вот интересно — ты тоже не в курсе, что в природе есть github/bitbucket/google code etc.?
Re[30]: Закон сохранения сложности
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 22.09.10 14:03
Оценка:
Здравствуйте, Курилка, Вы писали:
К>Извиняюсь, что встреваю, но вот интересно — ты тоже не в курсе, что в природе есть github/bitbucket/google code etc.?

ехал сегодня на трамвае, по дороге бигборды пропустил.
Расскажи подробнее
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.