Есть ли будущее у С#?
Будущее его несомненно
т.к.:
1) Он является копией Java с устранением недостатков последнего (благо, время на обнаружение недостатков было огромным)
2) Он продвигается великой и могучей корпорацией Micro$oft и денег в него вбахивается немеренно
но тут есть несколько НО:
1) Хочешь ли ты идти на поводу Мелксофта всю свою жизнь? Мне лично неудобно перед создателями языка Java - людьми действительно заслуживающими уважения в отличие от Некрософта. Зачем я буду писать на клоне их языка, который особых преимуществ не имеет?
2) У C# много недостатков, на которые некоторые программеры не обратят внимания, а некоторые наоборот забьют на его изучение в связи с этими недостатками. Например, C# считается языком независящим от платформы. Хотя на данный момент он поддерживается только на платформе windows. И ситуация в ближайшее время сильно не изменится. По крайней мере, Micro$soft уж точно для другой платформы ничего писать не будет. Есть, конечно Open Source проект Mono, который реализует платформу .NET в Линуксе и других юниксах, но он очень сырой пока. Да и непонятно к чему рвать себе задницу в данном случае? Чтобы помочь Некрософту?
3) У Java существует огромное сложившееся сообщество программеров во всем мире. Под него существует просто огромный инструментарий. И вообще, Java, действительно, платформонезависим
По этой теме в инете и в печатных изданиях много всего написано.
В общем, мой вывод такой - изучай Java, если хочешь стать профессиональным, высокооплачиваемым, уважаемым и свободным программистом. Если не хочешь - изучай C#
Но это всего лишь IMHO...
т.к.:
1) Он является копией Java с устранением недостатков последнего (благо, время на обнаружение недостатков было огромным)
2) Он продвигается великой и могучей корпорацией Micro$oft и денег в него вбахивается немеренно
но тут есть несколько НО:
1) Хочешь ли ты идти на поводу Мелксофта всю свою жизнь? Мне лично неудобно перед создателями языка Java - людьми действительно заслуживающими уважения в отличие от Некрософта. Зачем я буду писать на клоне их языка, который особых преимуществ не имеет?
2) У C# много недостатков, на которые некоторые программеры не обратят внимания, а некоторые наоборот забьют на его изучение в связи с этими недостатками. Например, C# считается языком независящим от платформы. Хотя на данный момент он поддерживается только на платформе windows. И ситуация в ближайшее время сильно не изменится. По крайней мере, Micro$soft уж точно для другой платформы ничего писать не будет. Есть, конечно Open Source проект Mono, который реализует платформу .NET в Линуксе и других юниксах, но он очень сырой пока. Да и непонятно к чему рвать себе задницу в данном случае? Чтобы помочь Некрософту?
3) У Java существует огромное сложившееся сообщество программеров во всем мире. Под него существует просто огромный инструментарий. И вообще, Java, действительно, платформонезависим
По этой теме в инете и в печатных изданиях много всего написано.
В общем, мой вывод такой - изучай Java, если хочешь стать профессиональным, высокооплачиваемым, уважаемым и свободным программистом. Если не хочешь - изучай C#
Но это всего лишь IMHO...
ИМХО ты не совсем прав
C# не есть цель продвигаемая MS, её целью является продвижение .NET, котороая уже действительно мультплатформенная, по крайней мере реализации под юниксы давно есть
под виндой .NET приложения работают гораздо лучше чем явишные
приложения .NET написаные в винде без проблем работают на юниксовой платформе
C# и .NET уже тем лучше явы что при его создании учитывался опыт разработки как и собственно Java так и JVM, и в то же время за плечами не было такого багажа старого когда какой сейчас наблюдается у SUN
зы: и если б SUN не заговнилась в своё время с лицензиями JAVA была б основным языком .NET а C# так и не появился бы
C# не есть цель продвигаемая MS, её целью является продвижение .NET, котороая уже действительно мультплатформенная, по крайней мере реализации под юниксы давно есть
под виндой .NET приложения работают гораздо лучше чем явишные
приложения .NET написаные в винде без проблем работают на юниксовой платформе
C# и .NET уже тем лучше явы что при его создании учитывался опыт разработки как и собственно Java так и JVM, и в то же время за плечами не было такого багажа старого когда какой сейчас наблюдается у SUN
зы: и если б SUN не заговнилась в своё время с лицензиями JAVA была б основным языком .NET а C# так и не появился бы
> .NET ... по крайней мере реализации под юниксы давно есть
Ты говоришь про Mono ? Она действительно сырая, и я не слышал чтоб ее где-то серьезно использовали.
Хотя не исключено, что за пару лет она дойдет до приемлемого уровня.
Ты говоришь про Mono ? Она действительно сырая, и я не слышал чтоб ее где-то серьезно использовали.
Хотя не исключено, что за пару лет она дойдет до приемлемого уровня.
Насчет говна с лицензиями - полностью согласен.
Sun вообще любит подобные ошибки, которые им потом чрезвычайно дорого стоят
Насчет .NET : я, наверное, просто не в курсе. Какими прогами поддерживается эта платформа в никсах?
Sun вообще любит подобные ошибки, которые им потом чрезвычайно дорого стоят
Насчет .NET : я, наверное, просто не в курсе. Какими прогами поддерживается эта платформа в никсах?
Под FreeBSD есть дистрибутив sscli (Mono & gyro) - валяется на сайте MS
см. выше
+ сами MS совместно с Corel/Inprise разрабатывают свою *nix реализацию
+ сами MS совместно с Corel/Inprise разрабатывают свою *nix реализацию
Что касается меня, то я полностью за мелкомягких... Желательно, что бы .NET и в будующем оставалась одноплаформенной, в переносе на другие системы не вижу необходимости. Все-таки в .NET очень много специфическоко от Windows, что не позволит выполнить миграцию на другие платформы. Что касается sscli - там пока много нет, а то что есть реализовано примитивно...
А на хрена в таком случае компилирование в байт-код?
Чтобы помедленнее работало?
Чтобы помедленнее работало?
что б было легче контролировать доступ и расход ресурсов, в частности памяти и дисковому пространству
=> никаких вирусов хотя бы
=> никаких вирусов хотя бы
>>А на хрена в таком случае компилирование в байт-код?
Не знаю, я тут недавно лично столкнулся с Javой - по моему .NET все таки рулит.
Что касается компиляции, вариант
C#(VB, Pascal, Perl, J#, JScript, C++) -> MSIL->(jit)исполнимый код
мне больше нравится. Как я понял, в jave код не компилируется к конечному виду, а интерпретируется, что по моему не есть хорошо. Но я в jave полный 0 так что не бейте, лучше поправьте меня...
Не знаю, я тут недавно лично столкнулся с Javой - по моему .NET все таки рулит.
Что касается компиляции, вариант
C#(VB, Pascal, Perl, J#, JScript, C++) -> MSIL->(jit)исполнимый код
мне больше нравится. Как я понял, в jave код не компилируется к конечному виду, а интерпретируется, что по моему не есть хорошо. Но я в jave полный 0 так что не бейте, лучше поправьте меня...
кстати и не факт что медленее
со всеми секьюрными приблудами которые анализируют низкоуровневый доступ к ресурсам и прочая... что сейчас в частности
мло того для каждой програмы можно проанализировать порядок загрузки ресурсов и соответствующим образом их подготовить, хотя бы сделать соответствуюющю дефрагментацию винта
некоторые наиболее часто используемые ресурсы прокешировать в уже готовом для загрузки в память виде
плоды подобного подхода можно наблюдать уже по тому насколько WinXP грузится быстрее чем W2K
а в .NET CLR такое можно будет провернуть практически с каждой програмой
со всеми секьюрными приблудами которые анализируют низкоуровневый доступ к ресурсам и прочая... что сейчас в частности
мло того для каждой програмы можно проанализировать порядок загрузки ресурсов и соответствующим образом их подготовить, хотя бы сделать соответствуюющю дефрагментацию винта
некоторые наиболее часто используемые ресурсы прокешировать в уже готовом для загрузки в память виде
плоды подобного подхода можно наблюдать уже по тому насколько WinXP грузится быстрее чем W2K
а в .NET CLR такое можно будет провернуть практически с каждой програмой
По поводу вирусов. Тут попались однажды. Как определил ? Ну не Касперским же ! Просто ни одна managed прога не запускалась ! А я ведь даже на них цифровой подписи (т.е. строгого имени с ключом- в терминах net) не поставил !
По поводу скорости все же спорить не буду... В конце концов есть "независимые" тесты...
Надеемся на мощные процы... Иначе как мы втретим Lohghorn ?
Надеемся на мощные процы... Иначе как мы втретим Lohghorn ?
Там еще и видюху вродь просят минимум радеон 9700 и это тока для работы системы 
Я считаю, что хорошее ПО не может писаться на Си-подобных языках без сильного изменения семантики.
Каждому делу --- свой язык.
Для высокоуровневых задач тяжело писать в низкоуровневом стиле, единственном, поддерживаемом Си.
Это ещё, к тому же, неудобно. Часто делаются ошибки.
То, что они делаются, очевидно.
От плюсов и диезов здесь ничего не зависит,
как был "for", так он и остался в своём уродском виде.
Любая виртуальная машина неудобна, если ты хочешь достигнуть производительности.
Это общее наблюдение, над такими задачами бьются всякие exokernel-щики.
Для некоторых ФЯП существую оптимизаторы, работающие с целыми программами.
Производительность достигается та же, что и на Си, а то и быстрее.
Вот в ту сторону и стоит смотреть.
Если тебе нужна переносимость, то есть два крайних способа, которые хорошо работают.
1. Путь высокоуровневого языка. Нет никакого доступа к низкому уровню. Классика языкостроения: чем более развит язык, тем лучше.
Переносимость с ВМ на ВМ (ФЯП, ЛЯП, ЯП СУБД).
2. Путь низкоуровневого языка с хорошими возможностями развития.
Нужна самодисциплина, чтобы оставлять возможность переносить низкоуровневую часть. Создание узкоспециализированных ЯП и ВМ.
Переносимость с прибора на прибор (Форт).
Си-подобные языки явно устарели.
Сложность каждодневно решаемых задач уже переросла возможности их развития.
---
"Держи, товарищ,
порох сухим!"
Каждому делу --- свой язык.
Для высокоуровневых задач тяжело писать в низкоуровневом стиле, единственном, поддерживаемом Си.
Это ещё, к тому же, неудобно. Часто делаются ошибки.
То, что они делаются, очевидно.
От плюсов и диезов здесь ничего не зависит,
как был "for", так он и остался в своём уродском виде.
Любая виртуальная машина неудобна, если ты хочешь достигнуть производительности.
Это общее наблюдение, над такими задачами бьются всякие exokernel-щики.
Для некоторых ФЯП существую оптимизаторы, работающие с целыми программами.
Производительность достигается та же, что и на Си, а то и быстрее.
Вот в ту сторону и стоит смотреть.
Если тебе нужна переносимость, то есть два крайних способа, которые хорошо работают.
1. Путь высокоуровневого языка. Нет никакого доступа к низкому уровню. Классика языкостроения: чем более развит язык, тем лучше.
Переносимость с ВМ на ВМ (ФЯП, ЛЯП, ЯП СУБД).
2. Путь низкоуровневого языка с хорошими возможностями развития.
Нужна самодисциплина, чтобы оставлять возможность переносить низкоуровневую часть. Создание узкоспециализированных ЯП и ВМ.
Переносимость с прибора на прибор (Форт).
Си-подобные языки явно устарели.
Сложность каждодневно решаемых задач уже переросла возможности их развития.
---
"Держи, товарищ,
порох сухим!"
Скорости мало не бывает.
Скорость машин за недавнее время выросла раза в два.
Кому-то от этого стало легче?
---
...Я работаю антинаучным аферистом...
Скорость машин за недавнее время выросла раза в два.
Кому-то от этого стало легче?
---
...Я работаю антинаучным аферистом...
Сейчас в лаборатория Меклософта стряпают несколько новых языком. К примеру F# (не знаю насколько он новый...) - нет ли какой инфы про них ?
Фортран?
Лучше бы они состряпали SML.
Один чёрт, если всё это будет байт-кодом.
Даже шитый код исполняется быстрее.
---
...Я работаю антинаучным аферистом...
Лучше бы они состряпали SML.
Один чёрт, если всё это будет байт-кодом.
Даже шитый код исполняется быстрее.
---
...Я работаю антинаучным аферистом...
Объясни мне, почему нельзя следить на уровне вызовов ядра и библиотек?
Вот как сейчас, например.
---
...Я работаю антинаучным аферистом...
Вот как сейчас, например.
---
...Я работаю антинаучным аферистом...
Что такое байт-код?
Факт.
У тебя появляется ещё одна прослойка между оборудованием и пользователем.
Есть люди, которых сильно волнует скорость шитого кода.
Байт-код --- один из самых медленных.
---
...Я работаю антинаучным аферистом...
У тебя появляется ещё одна прослойка между оборудованием и пользователем.
Есть люди, которых сильно волнует скорость шитого кода.
Байт-код --- один из самых медленных.
---
...Я работаю антинаучным аферистом...
Ты кодируешь высокоуровневые действия байтовыми инструкциями.
Получаешь программу для ВМ.
Байт-код --- язык этой ВМ.
---
...Я работаю антинаучным аферистом...
Получаешь программу для ВМ.
Байт-код --- язык этой ВМ.
---
...Я работаю антинаучным аферистом...
можно
только гораздо сложнее
И сейчас оно работает хреново мягко говоря
только гораздо сложнее
И сейчас оно работает хреново мягко говоря
только не надо приводить в примеры задачи какой-нить квантовой физики
для такого специальные компы заточеные под эти задачи делают
а вот приложения уровня MS Office, 1C и прочая гораздо выгоднее писать под .NET
для такого специальные компы заточеные под эти задачи делают
а вот приложения уровня MS Office, 1C и прочая гораздо выгоднее писать под .NET
F# - это "ocaml dot net". почти sml.
или ты настолько крут, что чувствуешь принципиальные различия sml и ocaml в плане написания кода?
или ты настолько крут, что чувствуешь принципиальные различия sml и ocaml в плане написания кода?
Вообще то ocaml и sml отличаются весьма сильно. Даже если не брать в расчет объекты и новую фичу с изменением синтаксиса.
Интресно, кстати, почему коммерческое программирование полностью игнорирует ФЯ.
Интресно, кстати, почему коммерческое программирование полностью игнорирует ФЯ.
По поводу "байт кода"
В .NET есть утилита ngen (Native Image Generator которая позволяет "сбросить" в специальный кэш т.н. native code (скомпилированные, не MSIL, т.е. чего Вы хотите). Но на самом деле JIT- компиляция эффективнее, и для пользовательских приложений применение ngen вряд ли оправдано. Почему ? Запустите ngen /show ... да ! блин неужели в кэше уже сидит весь .NET FCL ?
По поводу удобства написания приложения тут Вы правы. Но каждый вибирает любимый инструмент - кому то нравится Delphi, C++, мне лично C#. Еще, есть сейчас такое приложение MS BizTalk Server 2004 (2 бета) - по сложности наверное наравне в Excele'm, и по скорости тоже - сам пробовал. Так есть информация, что это почти 100% managed application...
В .NET есть утилита ngen (Native Image Generator которая позволяет "сбросить" в специальный кэш т.н. native code (скомпилированные, не MSIL, т.е. чего Вы хотите). Но на самом деле JIT- компиляция эффективнее, и для пользовательских приложений применение ngen вряд ли оправдано. Почему ? Запустите ngen /show ... да ! блин неужели в кэше уже сидит весь .NET FCL ?
По поводу удобства написания приложения тут Вы правы. Но каждый вибирает любимый инструмент - кому то нравится Delphi, C++, мне лично C#. Еще, есть сейчас такое приложение MS BizTalk Server 2004 (2 бета) - по сложности наверное наравне в Excele'm, и по скорости тоже - сам пробовал. Так есть информация, что это почти 100% managed application...
коммерческое программирование полностью игнорирует ФЯ ?
может быть о ФЯ и их коммерческом применении не пишут на форуме?
>Вообще то ocaml и sml отличаются весьма сильно. Даже если не брать в расчет объекты и новую фичу с изменением синтаксиса.
отсутствие слова datatype в камле - это сильное отличие? Если есть, что сказать - пиши в приват.
может быть о ФЯ и их коммерческом применении не пишут на форуме?
>Вообще то ocaml и sml отличаются весьма сильно. Даже если не брать в расчет объекты и новую фичу с изменением синтаксиса.
отсутствие слова datatype в камле - это сильное отличие? Если есть, что сказать - пиши в приват.
Я могу сказать, что мне не понравилось в камле.
Не понравилось то, что такой мощный язык требует разделения действий над целыми и вещественными числами на письме.
Либо я что-то плохо смотрел.
СМЛ мне попался раньше, чем окамл.
Ещё не нравится явное выделение ``match''.
Вместо
fun f a1 = b1 | f a2 = b2;
приходится писать
let f a = match a <чего-то там>.
Принципиальных различий я не вижу.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Не понравилось то, что такой мощный язык требует разделения действий над целыми и вещественными числами на письме.
Либо я что-то плохо смотрел.
СМЛ мне попался раньше, чем окамл.
Ещё не нравится явное выделение ``match''.
Вместо
fun f a1 = b1 | f a2 = b2;
приходится писать
let f a = match a <чего-то там>.
Принципиальных различий я не вижу.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Я могу привести требовательные к скорости задачи и без квантовой химии.
Сможешь мне объяснить, зачем текстовому редактору байт-код?
Что мешает его собирать сразу в машинный?
Для этого всё уже есть.
---
...Я работаю антинаучным аферистом...
Сможешь мне объяснить, зачем текстовому редактору байт-код?
Что мешает его собирать сразу в машинный?
Для этого всё уже есть.
---
...Я работаю антинаучным аферистом...
Из полезных отличий могу вспомнить стримы, на смену которым пришел препроцессор p4. Полиморфные варианты, более грамотные структуры. as и when в match.
Но в основе своей они похожи, я согласен. Только ocaml субъективно мне нравится больше, на нем приятнее писать.
2КОНТРА:
http://caml.inria.fr/oreilly-book/html/book-ora016.html#toc14
Но в основе своей они похожи, я согласен. Только ocaml субъективно мне нравится больше, на нем приятнее писать.
2КОНТРА:
http://caml.inria.fr/oreilly-book/html/book-ora016.html#toc14
function p1 -> expr1 | ...| pn -> exprn
Ещё одно я не понимаю в окамле.
Зачем ``let rec''?
В общем случае функции рекурсивны, тогда по принципу Дейкстры, надо выделять нерекурсивные.
Да и определить рекурсивность можно.
Лишнее слово?
---
...Я работаю антинаучным аферистом...
Зачем ``let rec''?
В общем случае функции рекурсивны, тогда по принципу Дейкстры, надо выделять нерекурсивные.
Да и определить рекурсивность можно.
Лишнее слово?
---
...Я работаю антинаучным аферистом...
fun map2 f nil nil = nil
| map2 f (h1::t1) (h2::t2) = (f h1 h2)::(map2 f t1 t2);
Я чего-то не понимаю, как это хорошо записать на окамле.
Получается, что нужно расписывать ``match''.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
| map2 f (h1::t1) (h2::t2) = (f h1 h2)::(map2 f t1 t2);
Я чего-то не понимаю, как это хорошо записать на окамле.
Получается, что нужно расписывать ``match''.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
ХЗ. Наверно какая-нибудь древняя оптимизация, оставшаяся со времен камла.
Вообще, с помощью p4 ты можешь создать сам какой угодно язык (на основе ocaml). Во всяком случая, я понял так, что это возможно и даже легко. Они сами прилагают модули для старого и нового написания. Так что заменишь там let rec на let, а let на let unrec и все дела.
Вообще, с помощью p4 ты можешь создать сам какой угодно язык (на основе ocaml). Во всяком случая, я понял так, что это возможно и даже легко. Они сами прилагают модули для старого и нового написания. Так что заменишь там let rec на let, а let на let unrec и все дела.
Препроцессить?
Ой-ё-ё-ё-ё!..
Вообще, получать из Окамла СМЛ с помощью препроцессора --- полный изврат.
Не, смысл в чём-то есть.
Только нафиг?
Получается, всё же, Окамл синтаксически чуть слабее.
О!
http://www.ps.uni-sb.de/~rossberg/SMLvsOcaml.html
---
...Я работаю антинаучным аферистом...
Ой-ё-ё-ё-ё!..
Вообще, получать из Окамла СМЛ с помощью препроцессора --- полный изврат.
Не, смысл в чём-то есть.
Только нафиг?
Получается, всё же, Окамл синтаксически чуть слабее.
О!
http://www.ps.uni-sb.de/~rossberg/SMLvsOcaml.html
---
...Я работаю антинаучным аферистом...
Я бы не сказал. У него есть расширения, которых в SML вообще нет. Правда судить о их полезности я не стану, опыта маловато.
Что касается препроцессора, то ты лучше почитай, что он из себя представляет. Я в свое время не смог до конца осознать всей глубины замысла его создателей, больно он навороченный. Это не то, что есть в С. Его можно использовать на манер Яка, например.
Что касается препроцессора, то ты лучше почитай, что он из себя представляет. Я в свое время не смог до конца осознать всей глубины замысла его создателей, больно он навороченный. Это не то, что есть в С. Его можно использовать на манер Яка, например.
Да, но при них же сидим с неестественными ``*.'' для умножения чисел. Зачем?
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
В принципе, это правильнее, чем позволять + работать и с целыми и с дробными. Например, выражение типа f x y = x + y становится несколько двусмысленным ибо в него можно подавать и целые и дробые. В Хаскеле, например, грамотно введены специальные типы - что-то типа ярлыка на обычные. И там + принимает значения с атрибутом Num. Можно реализовать для своего типа поддержку Num и он будет приниматься +. Это самый грамотный вариант, как мне кажется.
Кстати, помимо Mono существует еще pnet (Portable .NET причем совершенно независимый от Mono.
не понимаю, почему все свелось к сравнению семантики различных языков?
90% программистам это вообще не интересно.
А вот простота, сходство с++, отличная среда разработки для С# - это то, что обеспечит языку коммерческий успех.
MS не допустит его провала.
90% программистам это вообще не интересно.
А вот простота, сходство с++, отличная среда разработки для С# - это то, что обеспечит языку коммерческий успех.
MS не допустит его провала.
Я понимаю, почему "+" и "F+" в Форте --- нетипизированный язык.
Я не понимаю, почему в строго типизированных СМЛ --- "+", а в Окамле --- "+.".
Кстати, я понял почему "rec", "Схема навсегда."
"fun F P = E" --- то же, что и "val rec F = fn P => E"
"val V = E(V)" --- должно вычислять значение и переопределять "V", связывание после вычисления "E".
"fun F P = E(F)" --- не должно вычислять значение при определении "F", связывание до вычисления "F", входящего в "E".
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Я не понимаю, почему в строго типизированных СМЛ --- "+", а в Окамле --- "+.".
Кстати, я понял почему "rec", "Схема навсегда."
"fun F P = E" --- то же, что и "val rec F = fn P => E"
"val V = E(V)" --- должно вычислять значение и переопределять "V", связывание после вычисления "E".
"fun F P = E(F)" --- не должно вычислять значение при определении "F", связывание до вычисления "F", входящего в "E".
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Любая лишняя абстракция должна быть вырезана.
Лишняя виртуальная машина должна быть обоснована.
Даже Си++, который никак не является простым языком, можно собирать прямо в машинный код.
Среда для работы с ним есть и не одна.
Си# --- тот же бред, что и Си++.
Ещё о виртуальных машинах.
Есть такой ЯП, Форт.
Классический способ его реализации --- косвенный шитый код.
Так вот, сейчас все серьёзные разработчики упираются руками и ногами, из кожи вон лезут, лишь бы побольше кода _встроить_.
Это не то, чтобы не виртуальная машина, а очень даже невиртуальная.
Кстати, те, кто смотрел на "НЕТ", говорят, что МС предложил достаточно слабую машину.
Для некритичных задач это пойдёт, там, где торможение заметно не будет.
Зачем надо проигрывать время внутри ВМ, если можно получить ту же производительность, а то и большую, при использовании более простого, чем Си с плюсами-диезами, и значительно более безопасного языка программирования?
Только не надо говорить про тонны уже написанного под только появившуюся платформу кода.
---
...Я работаю дзен-бульдозеристом...
Лишняя виртуальная машина должна быть обоснована.
Даже Си++, который никак не является простым языком, можно собирать прямо в машинный код.
Среда для работы с ним есть и не одна.
Си# --- тот же бред, что и Си++.
Ещё о виртуальных машинах.
Есть такой ЯП, Форт.
Классический способ его реализации --- косвенный шитый код.
Так вот, сейчас все серьёзные разработчики упираются руками и ногами, из кожи вон лезут, лишь бы побольше кода _встроить_.
Это не то, чтобы не виртуальная машина, а очень даже невиртуальная.
Кстати, те, кто смотрел на "НЕТ", говорят, что МС предложил достаточно слабую машину.
Для некритичных задач это пойдёт, там, где торможение заметно не будет.
Зачем надо проигрывать время внутри ВМ, если можно получить ту же производительность, а то и большую, при использовании более простого, чем Си с плюсами-диезами, и значительно более безопасного языка программирования?
Только не надо говорить про тонны уже написанного под только появившуюся платформу кода.
---
...Я работаю дзен-бульдозеристом...
Потому что f x y = x+y и f x y = x +. y - разные функции. А в sml что получается? 'a->'a->'a?
Тогда, как быть с f g l = g::l; list = f (fn x y = x) (f plus []); Какой тип у list?
Про rec согласен. Я забыл, что let'ом объявляются и переменные. Это все объясняет.
Тогда, как быть с f g l = g::l; list = f (fn x y = x) (f plus []); Какой тип у list?
Про rec согласен. Я забыл, что let'ом объявляются и переменные. Это все объясняет.
Хм. Надо подумать.
В Poly/ML (что под рукой) оказалось так:
> fun f x y = x + y;
val f = fn : int -> int -> int
> fun g (x:real) y = x + y;
val g = fn : real -> real -> real
Но поведение Poly/ML отличается от поведения MosML в отношении целых и вещественных чисел.
Я пока не понял, в чём дело.
> fun f h t = h::t;
val f = fn : 'a -> 'a list -> 'a list
> val list = f (fn x => fn y => xf (op +) nil);
Error:
Can't unify Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int
with
'a ->
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int *
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int
(Incompatible types) Found near f(fn x => fn ... => ...f(+nil
Error:
Can't unify
'a ->
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int *
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int with
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int
(Type variable to be unified occurs in type) Found near
f(fn x => fn ... => ...f(+nil
Static errors (pass2)
> >
Надо осмыслить.
Честно говоря, я не очень давно знаком с МЛ-подобными.
Квадратные скобки мне непривычны, больше привык к круглым.
Вот слово ``fn'' вместо ``lambda'' мне нравится.
---
"...Надо учиться --- не напрягаясь!.." Акад. А. А. Бучаченко.
В Poly/ML (что под рукой) оказалось так:
> fun f x y = x + y;
val f = fn : int -> int -> int
> fun g (x:real) y = x + y;
val g = fn : real -> real -> real
Но поведение Poly/ML отличается от поведения MosML в отношении целых и вещественных чисел.
Я пока не понял, в чём дело.
> fun f h t = h::t;
val f = fn : 'a -> 'a list -> 'a list
> val list = f (fn x => fn y => xf (op +) nil);
Error:
Can't unify Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int
with
'a ->
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int *
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int
(Incompatible types) Found near f(fn x => fn ... => ...f(+nil
Error:
Can't unify
'a ->
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int *
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int with
Time.time/Time.time/Word8.word/Words.LargeWord.word/word/real/int
(Type variable to be unified occurs in type) Found near
f(fn x => fn ... => ...f(+nil
Static errors (pass2)
> >
Надо осмыслить.
Честно говоря, я не очень давно знаком с МЛ-подобными.
Квадратные скобки мне непривычны, больше привык к круглым.
Вот слово ``fn'' вместо ``lambda'' мне нравится.
---
"...Надо учиться --- не напрягаясь!.." Акад. А. А. Бучаченко.
Вот видишь, в ML грабли в такого рода функциях, а у OCaml в том, что операции дублируются. Как я уже говорил, только в Haskell все сделано красиво. Хотелось бы, чтобы подобный принцип внедрили и в другие языки.
В Java-е Jit-компиляция тоже уже некоторое время есть.
Если это столь необходимо, то лучше я останусь с круглыми скобками.
Особенно, раз во всех ML, есть подозрение, существуют грабли с map:
(map + '(1 2) '(3 4) '(5 6
(map + '(1 2 3) '(4 5 6) '(7 8 9
D. C. ad infinitum.
Строгая типизация, не допускающая нормального полиморфизма, не нужна.
---
...Я работаю дзен-бульдозеристом...
Особенно, раз во всех ML, есть подозрение, существуют грабли с map:
(map + '(1 2) '(3 4) '(5 6
(map + '(1 2 3) '(4 5 6) '(7 8 9
D. C. ad infinitum.
Строгая типизация, не допускающая нормального полиморфизма, не нужна.
---
...Я работаю дзен-бульдозеристом...
Байт-код нужен для переносимости между разными процессорами в первую очередь.
Например, .Net Compact Framework работает на разных карманных компьютерах с процессорами основанными на разной архитектуре.
ps
И вообще, чем более на высокоуровневом языке мы пишем, тем больше остается возможностей для оптимизации под каждую конкретную машину.
Или если перефразировать, чем на более высокоуровневой записи мы отдаем программу пользователю, тем больше у него возможностей для оптимизации программы под конкретную платформу, под конкретное окружение.
Байт-код и есть чуть более высокоуровневая запись.
Например, .Net Compact Framework работает на разных карманных компьютерах с процессорами основанными на разной архитектуре.
ps
И вообще, чем более на высокоуровневом языке мы пишем, тем больше остается возможностей для оптимизации под каждую конкретную машину.
Или если перефразировать, чем на более высокоуровневой записи мы отдаем программу пользователю, тем больше у него возможностей для оптимизации программы под конкретную платформу, под конкретное окружение.
Байт-код и есть чуть более высокоуровневая запись.
Как мне нравится, когда люди сравнивают два языка, зная один и то, видимо, по-наслышке 
А в Java, по-твоему, синтаксис не C++, а какой-то другой? Или что ты хотел этим сказать?
Я бы сказал, что в c# синтаксис Java, а в Java синтаксис C++
А в Java, по-твоему, синтаксис не C++, а какой-то другой? Или что ты хотел этим сказать?
Я бы сказал, что в c# синтаксис Java, а в Java синтаксис C++
Ну и хорошо, что есть. Что то Вы ушли от темы. Вот приведу один перл из Дж. Рихтера (из его "классической" книги по .NET)
Even though today’s CPUs can’t execute IL instructions directly, CPUs of the future might
have this capability. To execute a method, its IL must first be converted to native CPU
instructions. This is the job of the CLR’s JIT (just-in-time) compiler.
Even though today’s CPUs can’t execute IL instructions directly, CPUs of the future might
have this capability. To execute a method, its IL must first be converted to native CPU
instructions. This is the job of the CLR’s JIT (just-in-time) compiler.
Вообще говоря, Sun такой процессор сделала и на него весь расчет и был, что он заменит нам все остальные процессоры по возможности
Но с этим процессором она облажалась, как и со многими другими вещами
В результате подобной лажи мы и видим то, что видим, то есть процветание c#
Но с этим процессором она облажалась, как и со многими другими вещами
В результате подобной лажи мы и видим то, что видим, то есть процветание c#
А еще "байт код", а вернее MSIL нужет для возможности ингеграции разных языков программирования. Разве не здорово, написать один класс A на C++, далее на Basice создать класс-потомок, и все это потом юзать хоть в Pascale хоть на C# используя единую модель программирования ?
PS. Не говорите, что мол это уже проходили (DLL, COM - это не то...)
PS. Не говорите, что мол это уже проходили (DLL, COM - это не то...)
А можно поподробнее про то как она облажалась - я не слышал, очень интересно ...
Как ФЯП используются для "живых" (событийных) задач, а не для вычислительных задач?
Допустим, есть вот такие соглашения:
Но нам надо не однократно вычислить такие соглашения, а постоянно их поддерживать на всем жизненном цикле программы, т.е. при изменении OtherObject.Items должен автоматом (если надо) менятся minItem, а также goodItems.
Помогут ли нам чем-то ФЯП-ы при решений данной задачи? Если особо не помогают, то тогда я не вижу особой разницы между ФЯП-ом и C-подобными, т.к. все равно ФЯП не позволит решать реальные задачи.
Допустим, есть вот такие соглашения:
items = OtherObject.Items;
minItem = min(items);
goodItems = filter(items, {item.IsGood});
Но нам надо не однократно вычислить такие соглашения, а постоянно их поддерживать на всем жизненном цикле программы, т.е. при изменении OtherObject.Items должен автоматом (если надо) менятся minItem, а также goodItems.
Помогут ли нам чем-то ФЯП-ы при решений данной задачи? Если особо не помогают, то тогда я не вижу особой разницы между ФЯП-ом и C-подобными, т.к. все равно ФЯП не позволит решать реальные задачи.
Неужели эта проблема как-то решается байт-кодом?
К чему вообще кодировать файл, чтобы была возможность использовать его другими языками?
Мне кажется, здесь был бы полезен единый формат, то есть, использовать XML или что-то в этом роде
Но приведение к практически машинному коду, здесь может только все запутать. Это, видимо, чисто мелкософтовская задумка.
Но я могу и ошибаться, т.к. деталей не знаю
К чему вообще кодировать файл, чтобы была возможность использовать его другими языками?
Мне кажется, здесь был бы полезен единый формат, то есть, использовать XML или что-то в этом роде
Но приведение к практически машинному коду, здесь может только все запутать. Это, видимо, чисто мелкософтовская задумка.
Но я могу и ошибаться, т.к. деталей не знаю
А теперь ты мне объясни, зачем нужен байт-код для переносимости, если можно просто собрать под отдельную платформу?
Или ещё хуже, если можно собрать на _этой_ же платформе более быстрый шитый код?
Ты, вот, упомянул про оптимизацию. Тем хуже для тебя.
Зачем отказываться от оптимизации при сборке под конкретную платформу в пользу байт-кода, написанного под заведомо худшую платформу ВМ?
У тебя идёт потеря времени в двух местах: из-за плохого представления алгоритма в байт-коде ВМ и из-за плохого представления байт-кода на целевой машине.
Даже в самом лучшем случае, когда всё хорошо ложится ты получаешь проигрыш на программной интерпретации байт-кода.
Мало того, что отказались от оптимизации, так ещё ввели потери при интерпретации.
---
...Я работаю дзен-бульдозеристом...
Или ещё хуже, если можно собрать на _этой_ же платформе более быстрый шитый код?
Ты, вот, упомянул про оптимизацию. Тем хуже для тебя.
Зачем отказываться от оптимизации при сборке под конкретную платформу в пользу байт-кода, написанного под заведомо худшую платформу ВМ?
У тебя идёт потеря времени в двух местах: из-за плохого представления алгоритма в байт-коде ВМ и из-за плохого представления байт-кода на целевой машине.
Даже в самом лучшем случае, когда всё хорошо ложится ты получаешь проигрыш на программной интерпретации байт-кода.
Мало того, что отказались от оптимизации, так ещё ввели потери при интерпретации.
---
...Я работаю дзен-бульдозеристом...
в .Net-е нет интерпретации
могу повторить еще раз: в .Net-е байт-код не интерпретируется
могу повторить еще раз: в .Net-е байт-код не интерпретируется
Ну я точно не знаю. Но процессоры, которые работают, как Java-машины широко используются во всяких магнитных картах. Насколько я знаю у sun был план перевести все, вплоть до домашних компов на такие процессоры. Ну а как она облажалась - понятно. Не на то замахнулась. Да и не востребованным это все оказалось. Деньги-то ведь не у программеров, а у толстых дяденек в этом не шарящих ни хера. Java вообще сильно опередил свое время, поэтому у него такая трагичная судьба.
Про эти процессоры нам как-то Богачев рассказывал. Боюсь наврать, но, возможно, в Sparc'ах такая возможность есть.
Про эти процессоры нам как-то Богачев рассказывал. Боюсь наврать, но, возможно, в Sparc'ах такая возможность есть.
Кто будет собирать программу под данную конкретную платформу?
Разработчик? А откуда он вообще знает о существании платформы, которая стоит у тебя дома?
Пользователь? В каком виде тогда ему будет передаватся программа?
Разработчик? А откуда он вообще знает о существании платформы, которая стоит у тебя дома?
Пользователь? В каком виде тогда ему будет передаватся программа?
Even though today’s CPUs can’t execute IL instructions directly, CPUs of the future might
have this capability.
а может наоборот?.. Кажется на сайте "Эльбруса" читал что у них на каком-то из процов в качестве байт-кода использовались инструкции Sun'а, который компилялись специальной прогой в родные (микро?)команды с оптимизацией (перестановкой инструкций и пр) что как-то позволяло упростить работу конвейера и немеряно ускорить работу прогу. Подробностей не помню. Так что вполне возможно, что шибко высокоуровневых процессоров не будет никогда, но высокоуровневый код будет использоваться для хранения и транспортировки прог.
VMS была написана не менее, чем на десятке ЯП.
ELF не зависит от того, на чём ты писал программу.
OMF, COFF, кстати, тоже.
Это, действительно, проходили.
И способы передачи данных изобретали.
Языки программирования, кстати, различаются не только обозначениями.
В некоторых из них классов не бывает.
Как класса.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
ELF не зависит от того, на чём ты писал программу.
OMF, COFF, кстати, тоже.
Это, действительно, проходили.
И способы передачи данных изобретали.
Языки программирования, кстати, различаются не только обозначениями.
В некоторых из них классов не бывает.
Как класса.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
@Это, видимо, чисто мелкософтовская задумка.
Да но, это
1) заставило часть программистов, пишущих на C++ перейти на C#
2) заставило часть программистов, пишущих на java перейти на J# (не верю !)
3) сохранить миллионую армию VB-разработчиком
в конечном итоге все бабло -> MS
Да но, это
1) заставило часть программистов, пишущих на C++ перейти на C#
2) заставило часть программистов, пишущих на java перейти на J# (не верю !)
3) сохранить миллионую армию VB-разработчиком
в конечном итоге все бабло -> MS
Ты - типичный пользователь (обычная домохозяйка).
Откуда ты знаешь, какую версию программы надо скачать и под какую платформу, чтобы это заработало на том ящике, который стоит у тебя дома?
Откуда ты знаешь, какую версию программы надо скачать и под какую платформу, чтобы это заработало на том ящике, который стоит у тебя дома?
5
Для СРВ есть более другие ФЯП.
Смотреть в сторону Эрланга и Лиспа.
Кроме того, речь не о ЯП, а о ВМ.
Которая нужна, как собаке пятое колесо.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Смотреть в сторону Эрланга и Лиспа.
Кроме того, речь не о ЯП, а о ВМ.
Которая нужна, как собаке пятое колесо.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
На уровне web-сервисов, xml смотрится отлично, т.к. затраты на передачу через среду (интернет) полностью перекрывают время, которые уходят на парсинг/unparse-инг xml-я.
На уровне же код <-> код, скорость работы становятся не мало важным фактором.
На уровне же код <-> код, скорость работы становятся не мало важным фактором.
То есть, в "НЕТ" программы никогда не исполняются?
Очень хорошо.
Начерта он нужен?
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Очень хорошо.
Начерта он нужен?
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Байт-код в .Net-е компилируется.
а еще меня радует что прога с весьма нетривиальной логикой и довольно богатым интерфейсом, но без особых рюшечек (типа битмепов в ресурсах) занимает 100-200 килобайт и при этом нормально архивируется. Не знаю, заслуга ли это байт-кода или фреймворка, но радует 
Посмотри на ГНУ-Линукс и на БСД.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Перед исполнение они КОМПИЛИРУЮТСЯ в МАШИННЫЙ КОД. В чем класс !
Каким будет код для данной задачи на приведенных тобой, в качестве примера, языках?
Посмотри, как это делается в ГНУ-Линукс и БСД.
Автоматизация сборки --- не настолько большая проблема.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Автоматизация сборки --- не настолько большая проблема.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Ты можешь назвать много бизнес приложений, которые распространяются в исходных кодах?
ps
AFAIK, как раз в бизнес-приложениях сейчас крутятся основые деньги.
ps
AFAIK, как раз в бизнес-приложениях сейчас крутятся основые деньги.
Ну и нафиг он тогда нужен?
Использовать исходные тексты.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Использовать исходные тексты.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
так они ж в исходниках идут вроде... Правда есть еще какие-то RPM, только я не знаю насколько они переносимы и оптимизабельны под конкретную платформу
Эти приложения ничего не стоит собрать под конкретные платформы.
Раз денег много и платформ не такое большое количество.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Раз денег много и платформ не такое большое количество.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Кстати, специалисты .NET. Вы заметили, что команда ngen /show дает следующие сбоки: mscorlib, System, System.Drawing, System.Windows.Forms, System.XML - этоже основа FCL - что неужели при выполнении .NET - программы практически все достается из native кэша и основные функции .нета используются без jit-компиляции ?
1) Любой код должен быть превращен в машинный код
2) По-моему, ты не сильно разобрался как работает JVM
3) Возьмем охрененных размеров программу и подождем часик другой пока она ВСЯ перекомпилируется в машинный код Так что ли?
2) По-моему, ты не сильно разобрался как работает JVM
3) Возьмем охрененных размеров программу и подождем часик другой пока она ВСЯ перекомпилируется в машинный код
Так что ли?Байт код еще может быть полезен при передаче класса на другую машину, поскольку чисто теоретически там может быть не интел с виндами, да и безопасность опять же. Но я уверен, что эту задачу можно решить и без .Net.
Java - мултиплатформенная. Следовательно не оптимизирована ни для одной из них.
.NET - одноплатформенный, но оптимизироваа под Windows.
(C) не я
Программеров java - не обижайтесь, без работы Вы не останетесь...
.NET - одноплатформенный, но оптимизироваа под Windows.
(C) не я
Программеров java - не обижайтесь,
без работы Вы не останетесь...а вот это интересный вопрос, в чем крутятся основные деньги... В серийных приложениях (не допустима поставка в исходниках в эксклюзивных (как правило только в исходниках) или в настройке под конкретного клиента серийное приложение (1С, ERP, веб)?
Потому что, все рюшечки и окошечки во фреймворке. Это, считай, та же dll.
Полный бред делать одноплатформенный язык с байт-кодом
Ассемблер уже таковым языком является: байт-код отличный получается и вообще, куча преимуществ
Ассемблер уже таковым языком является: байт-код отличный получается и вообще, куча преимуществ
ну а насчет логики, она в байт-коде компактнее чем в нейтив или нет?
> а вот это интересный вопрос, в чем крутятся основные деньги...
этот вопрос интересен манагеру, так как деньги ему достанутся
а здесь всё больше с точки зрения программера обсуждают
этот вопрос интересен манагеру, так как деньги ему достанутся
а здесь всё больше с точки зрения программера обсуждают
Но нам надо не однократно вычислить такие соглашения, а постоянно их поддерживать на всем жизненном цикле программы, т.е. при изменении OtherObject.Items должен автоматом (если надо) менятся minItem, а также goodItems.
Как-то ты туманно выразился. Что конкретно ты хочешь? Ведь просто пересчитывать, что надо, при поступлении нового итема не так уж и сложно чуть ли не на любом языке.
ну так манагеры в конечном счете решают как должны развиватся ЯП, а это в свою очередь интересно программерам, т.к. влияет на них
Конечно в 3-х, потому что именно там клиенты готовы платить наибольшие деньги.
Исходники пока не достигли нормальной высокоуровневности, чтобы с ними можно было удобно работать.
Исходники пока не достигли нормальной высокоуровневности, чтобы с ними можно было удобно работать.
по-разному они развиваются, и выбор есть поэтому
Компактнее в байт коде, ocaml'овском. Потому, что там задача сама по себе более просто решается.
А как работает java VM ? Объясните. Как я понимаю при первой компиляции имеем class. Что он содержит ? В каком виде там например записана команда x= a + b ? При исполнении интерптетатор java делает parse кода и превращает в мащинный код (add). Вопрос: если я помещу эту операцию присвоения с цикл for на 100000000. Сколько раз будет производится интерпретация кода (parse) и сколько раз будет выполнена машинная команда add ? Видимо я тут что -то не допонял в java.
Как можно было заметить формальная постановка задачи уложилась в 3 строчки.
На С-подобном языке (да и на ФЯП тоже) для описания потребуется уже пара страниц кода, а для наиболее оптимального решения уже скорее всего несколько десятков страниц кода.
> Как-то ты туманно выразился. Что конкретно ты хочешь?
Я хочу, чтобы в переменной minItem находился всегда минимальный элемент от коллекции OtherObject.Items, а в коллекции goodItems лежали всегда только хорошие элементы. Причем эти условия должны выполнятся при любых изменениях коллекции OtherObject.Items.
> Ведь просто пересчитывать, что надо, при поступлении нового итема не так уж и сложно чуть ли не на любом языке.
А что делать, если добавили 3 элемента?
А если удалили один?
Удалили несколько?
Изменили один?
Изменили несколько?
Заменили полностью коллекцию?
Для каждого их этих случаев ты будешь писать отдельных код?
На С-подобном языке (да и на ФЯП тоже) для описания потребуется уже пара страниц кода, а для наиболее оптимального решения уже скорее всего несколько десятков страниц кода.
> Как-то ты туманно выразился. Что конкретно ты хочешь?
Я хочу, чтобы в переменной minItem находился всегда минимальный элемент от коллекции OtherObject.Items, а в коллекции goodItems лежали всегда только хорошие элементы. Причем эти условия должны выполнятся при любых изменениях коллекции OtherObject.Items.
> Ведь просто пересчитывать, что надо, при поступлении нового итема не так уж и сложно чуть ли не на любом языке.
А что делать, если добавили 3 элемента?
А если удалили один?
Удалили несколько?
Изменили один?
Изменили несколько?
Заменили полностью коллекцию?
Для каждого их этих случаев ты будешь писать отдельных код?
В чем плюсы байт-кода по сравнению с исходниками на каком-либо ЯП:
1) Меньше размер
2) Возможность защиты копирайта и пр.
3) Свобода выбора ЯП для разработчика - не надо ломать себе голову, окажется ли компилятор для этого ЯП у конечного пользователя
В чем плюсы байт-кода по сравнению с бинарником, откомпилированным под конкретную архитектуру:
1) Возможность откомпилировать байт код с конретными флагами оптимизации на конечной машине. Если же разработчик сам будет компилировать свой продукт под всевозможные ОСи и всевозможные архитектуры со всевозможными флагами оптимизации, угадайте, что из этого получится
2) (Теоретическая) возможность интерпретации байт-кода. Какие возможности это предоставляет для отладки, я думаю, никому говорить не надо.
1) Меньше размер
2) Возможность защиты копирайта и пр.
3) Свобода выбора ЯП для разработчика - не надо ломать себе голову, окажется ли компилятор для этого ЯП у конечного пользователя
В чем плюсы байт-кода по сравнению с бинарником, откомпилированным под конкретную архитектуру:
1) Возможность откомпилировать байт код с конретными флагами оптимизации на конечной машине. Если же разработчик сам будет компилировать свой продукт под всевозможные ОСи и всевозможные архитектуры со всевозможными флагами оптимизации, угадайте, что из этого получится
2) (Теоретическая) возможность интерпретации байт-кода. Какие возможности это предоставляет для отладки, я думаю, никому говорить не надо.
но ведь это крупные клиенты, а их мало... например, хозяин сайта потратит 2k на Win+IIS+SQL Server и 10k на веб-программистов, т.е. если бы проги покупали только сайтовладельцы, все было бы как ты говорил. Но на этот сервак приходится 1000 посетителей которые купили серийную винду за 150 каждый (не в РФ, конечно) с серийными WinZip и CS ...
Но даже если бы большая часть денег была в "настройке" серийного софта, то проблем в распространением исходников не было, "настройки" только в исходниках и поставляются
Но даже если бы большая часть денег была в "настройке" серийного софта, то проблем в распространением исходников не было, "настройки" только в исходниках и поставляются
полагаю, что аналогично ассемблеру:
mark: add
goto mark
типа того, если на пальцах, только со счетчиком
mark: add
goto mark
типа того, если на пальцах, только со счетчиком
Может тебе C++ поможет со всяческими шаблонами?
Так его уж давненько изобрели...
Так его уж давненько изобрели...
это конкретная задача или просто гимнастика для ума?.. Могу предложить хинт для си-подобного языка С++: делаешь heap (или две штуки, надо подумать) со ссылками на элементы коллекции. При добавлении/удалении элементов корректируешь heap, на это идет O(log2(колво элементов в коллекции операций. Если пригодится, с тебя пиво
> Я хочу, чтобы в переменной minItem находился всегда минимальный элемент от коллекции OtherObject.Items, а в коллекции goodItems лежали всегда только хорошие элементы. Причем эти условия должны выполнятся при любых изменениях коллекции OtherObject.Items.
Типичный пример такого подхода - это, например, горизонтальный скроллер в текстовом редакторе.
Его видимость задается простым формальным условием:
HorScrollBar.Visible = Max(Lines, {Line.Width}) < Window.Width
Далее это условие должно автоматом перевычесляться при изменении текста в окне, причем хочется, чтобы перевычисления происходили максимально оптимальным образом. Понятно, что если мы добавили одну букву, то ради этого бегать еще раз по всем строкам не надо, но с другой стороны, если мы сделали большой сложный paste, то выгоднее может быть просто все перевычислить, чем анализировать вставку каждой отдельного символа из paste-а.
Типичный пример такого подхода - это, например, горизонтальный скроллер в текстовом редакторе.
Его видимость задается простым формальным условием:
HorScrollBar.Visible = Max(Lines, {Line.Width}) < Window.Width
Далее это условие должно автоматом перевычесляться при изменении текста в окне, причем хочется, чтобы перевычисления происходили максимально оптимальным образом. Понятно, что если мы добавили одну букву, то ради этого бегать еще раз по всем строкам не надо, но с другой стороны, если мы сделали большой сложный paste, то выгоднее может быть просто все перевычислить, чем анализировать вставку каждой отдельного символа из paste-а.
Схема:
(define (event)
(let loop (items (get-items
(begin
(set! good-items (filter good items
(set! min (item-min items
(loop (get-items
)
Далее ``event'' вешается на ногу или чего там тебе надо.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
(define (event)
(let loop (items (get-items
(begin
(set! good-items (filter good items
(set! min (item-min items
(loop (get-items
)
Далее ``event'' вешается на ногу или чего там тебе надо.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
не понял, зачем в данной задаче heap-ы?
Нет, вы не совсем поняли. Меня вот такой вопрос интересует. Например язык MSIL содержит т.н. оптокод с номером 58 (OpCodes.Add ) - увидев его, по идее компилятор должен сгенерировать машинный код, выполняющий сложение. Так вот, если такой код пустить в цикле N, тогда он будет всего 1 раз компилироваться в машинный код, а сам машинный код будет выполнятся N раз. А как работает JAVA, если утверждается, что код интерпретируется ? Существует же наверное какая-то оптимизация кода ?
Исходники достигли такой высокоуровневости ещё лет двадцать тому назад.
Просто тебе об этом не сказали.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Просто тебе об этом не сказали.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
а затем, что для пересчета минимума (или максимума) длин строк не нужно обходить все N строк (делать N операций а достаточно log2(N) операций, что для больших текстов м.б. существенно
и где здесь хоть какая-то высокоуровневность? Что дальше делать с этими событиями? Сколько будет событий для приведенной мной задачи?
Одно? Исходная коллкекция поменялась?
Десять? Или сколько?
Все равно получается, что для каждого конкретного случая: добавилось один элемент, добавилось много элементов, умер один элемент, умерло много элементов, изменился один элемент, изменилось много элементов писать каждый раз код руками.
Почему каждый из этих случаев программист должен Хотя это запросто мог сделать и компилятор.
Одно? Исходная коллкекция поменялась?
Десять? Или сколько?
Все равно получается, что для каждого конкретного случая: добавилось один элемент, добавилось много элементов, умер один элемент, умерло много элементов, изменился один элемент, изменилось много элементов писать каждый раз код руками.
Почему каждый из этих случаев программист должен Хотя это запросто мог сделать и компилятор.
1. Возьми gzip или bzip2. Или ещё что-то.
2. Копирайт к делу никак не относится. Книги тоже копирайчены. Однако ты можешь посмотреть, как они сделаны.
3. а) Общий знаменатель может быть высокоуровневым.
б) Можно проводить сборку на сервере.
1. Посмотри, как создаётся загрузочная дискета Plan-9 у Bell Labs.
2. а) Отладчики существуют.
б) На целевой машине надо исполнять, а не отлаживать.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
2. Копирайт к делу никак не относится. Книги тоже копирайчены. Однако ты можешь посмотреть, как они сделаны.
3. а) Общий знаменатель может быть высокоуровневым.
б) Можно проводить сборку на сервере.
1. Посмотри, как создаётся загрузочная дискета Plan-9 у Bell Labs.
2. а) Отладчики существуют.
б) На целевой машине надо исполнять, а не отлаживать.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Приведи пример. Я, конечно, верю, что в некоем идеальном мире такие исходники есть. Но если они такие хорошие, то почему их нет на моем компьютере?
Блин, а задача то наипростейшая. В .NET есть даже готовое решение. Называется System.Collections
У java вроде как два режима, интерпретация и преобразование в байт-код
Не думаю, что в c# есть какие-то изменения, связанные с этим
Не думаю, что в c# есть какие-то изменения, связанные с этим
То есть, если я правильно понял, хочется, чтобы алгоритм автоматически преобразовался в "инкрементальную" версию, в которой при небольшом изменении входных параметров не перевычислялось бы всё целиком?
Ну можно так сделать, да
Какие вопросы-то?
Как я понял, такие:
Q. На каком языке удобно записывать такие алгоритмы?
A. На специально разработанном для этой задачи?
Q. На каком языке удобно писать преобразователь?
A. На каком умеешь ФЯ тут совсем неплохо будет смотреться.
Ну можно так сделать, да
Какие вопросы-то?
Как я понял, такие:
Q. На каком языке удобно записывать такие алгоритмы?
A. На специально разработанном для этой задачи?
Q. На каком языке удобно писать преобразователь?
A. На каком умеешь
ФЯ тут совсем неплохо будет смотреться.Близкое к оптимальному перевычисление и просто перевычисление - это уже две разные задачи. Для оптимального перевычисления тебе придется сильно расширить свою формальную постановку задачи.
А в самом тупом варианте задача решается просто для любых изменений массива.
А в самом тупом варианте задача решается просто для любых изменений массива.
говно написал
в общем есть компиляция на лету и есть полная компиляция
и работают они по-разному
в общем есть компиляция на лету и есть полная компиляция
и работают они по-разному
Таков заданный уровень при постановке задачи.
В обратную: DSL на 32 строки длиной не более 64 знаков, например, управление оборудованием терминала изобразить на Си++ сможешь?
Чтение с пульта, разбор конструкций и вызов ОС.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
В обратную: DSL на 32 строки длиной не более 64 знаков, например, управление оборудованием терминала изобразить на Си++ сможешь?
Чтение с пульта, разбор конструкций и вызов ОС.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
интерпретация чего ? class- файлов ? Тогда что же такое байт-код в жабе ? Я понимал, что это и есть class.
это называется "не учи отца и баста"
а что, разве в НЕТе есть что-то типа make_heap/push_heap/pop_heap?
а что, разве в НЕТе есть что-то типа make_heap/push_heap/pop_heap?
Насчет Plan9 я тоже сильно задумался, когда качал загрузочный флоп
Но я пришел к выводу, что там для каждого варианта действительно уже есть готовый файл
А ты считаешь, что генериться?
Но я пришел к выводу, что там для каждого варианта действительно уже есть готовый файл
А ты считаешь, что генериться?
Твои личные трудности.
www.forth.com и www.ultratechnology.com тебе в помощь, где-то там лежит история с телескопами и ещё много других.
``Success stories.''
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
www.forth.com и www.ultratechnology.com тебе в помощь, где-то там лежит история с телескопами и ещё много других.
``Success stories.''
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
на Си++ изобразить можно что угодно, особенно если пользоваться сторонними библиотеками... 
знать бы что ты просишь...
знать бы что ты просишь... Тогда что есть полная компиляция ? Это когда на выходе имею обычный PE - exe вроде того, что написан на VC6.0 ?
У тебя все равно не будет log2(N т.к. у тебя или вставка новой строки, или поиск будет занимать в общем случае log(N) действий.
При этом легко придумывается алгоритм, который в большинстве случаев работает за константное время.
Например, просто помнить длину самой длинной строки.
При этом легко придумывается алгоритм, который в большинстве случаев работает за константное время.
Например, просто помнить длину самой длинной строки.
Ничего не мешает и сгенерить.
Я препятствий не вижу.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Я препятствий не вижу.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Сторонняя библиотека --- glibc. Иные --- урезать.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
у тебя неправильная постановка задачи: если самая длинная строка удаляется достаточно регулярно, то мой алгоритм будет выигрывать, а если самую длинную строку трогать не будут или она будет только расти, то... сам понимаешь
В общем, без дальнейшего уточнения задача не имеет оптимального решения
В общем, без дальнейшего уточнения задача не имеет оптимального решения
нет, все компилируется в class
но как раз его в машинный код можно компилировать по-разному
то о чем ты говорил, как об особенности шарпа
но как раз его в машинный код можно компилировать по-разному
то о чем ты говорил, как об особенности шарпа
> Q. На каком языке удобно записывать такие алгоритмы?
> A. На специально разработанном для этой задачи?
А такой уже есть? Если такого нет, то ФЯП мне мало помогают.
> Q. На каком языке удобно писать преобразователь?
> A. На каком умеешь ФЯ тут совсем неплохо будет смотреться.
Здесь согласен.
зы
Я только хотел сказать, что ФЯП также далеки от требований реальных задач, как и C-подобные языки.
> A. На специально разработанном для этой задачи?
А такой уже есть? Если такого нет, то ФЯП мне мало помогают.
> Q. На каком языке удобно писать преобразователь?
> A. На каком умеешь ФЯ тут совсем неплохо будет смотреться.
Здесь согласен.
зы
Я только хотел сказать, что ФЯП также далеки от требований реальных задач, как и C-подобные языки.
> Копирайт к делу никак не относится
Еще как относится. Та позиция, с которой смотришь ты (пользователь - халявщик) далеко не единственная. Проблема защиты программ - очень актуальна.
> а) Общий знаменатель может быть высокоуровневым.
А по-русски?
> б) Можно проводить сборку на сервере.
И мы переходим к пункту 2 - распространение бинарников
> Посмотри, как создаётся загрузочная дискета Plan-9 у Bell Labs.
Вот за что я тебя не люблю, так это за показушное пальцекидательство. Ты прекрасно знаешь, что я скорее всего понятия не имею как она собирается. Так почему бы тебе сразу не сказать идею, вместо того чтобы кидать пальцы?
> а) Отладчики существуют.
> б) На целевой машине надо исполнять, а не отлаживать.
Ты не понял. Я хотел сказать, что отлаживать интерпретируемую прогу не в пример удобнее компилируемой. Отлаживать она будет конечно на инструментальной машине, но для этого все равно нужен байт-код.
Еще как относится. Та позиция, с которой смотришь ты (пользователь - халявщик) далеко не единственная. Проблема защиты программ - очень актуальна.
> а) Общий знаменатель может быть высокоуровневым.
А по-русски?
> б) Можно проводить сборку на сервере.
И мы переходим к пункту 2 - распространение бинарников
> Посмотри, как создаётся загрузочная дискета Plan-9 у Bell Labs.
Вот за что я тебя не люблю, так это за показушное пальцекидательство. Ты прекрасно знаешь, что я скорее всего понятия не имею как она собирается. Так почему бы тебе сразу не сказать идею, вместо того чтобы кидать пальцы?
> а) Отладчики существуют.
> б) На целевой машине надо исполнять, а не отлаживать.
Ты не понял. Я хотел сказать, что отлаживать интерпретируемую прогу не в пример удобнее компилируемой. Отлаживать она будет конечно на инструментальной машине, но для этого все равно нужен байт-код.
да ты чё! мне без STL жизнь не мила
вообще, поясни задачу, м.б. там и стандартный средств хватит?
вообще, поясни задачу, м.б. там и стандартный средств хватит?
О! Простейший монитор оборудования.
Чтение-запись портов, программирование выдач и чтения последовательностей.
4Кб demo, использовать только штатные средства языка.
Для Си допустима только glibc.
Если нет ФВВ, то они:
void outb(int, int void outw(int, int int inb(int int inw(int).
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Чтение-запись портов, программирование выдач и чтения последовательностей.
4Кб demo, использовать только штатные средства языка.
Для Си допустима только glibc.
Если нет ФВВ, то они:
void outb(int, int void outw(int, int int inb(int int inw(int).
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Так вот, если мы записываем задачу в терминах HorScrollBar.Visible = min(Lines, Line.Width) < Window.Width, то программа как раз может на основе статистики (на основе еще какой-то информации) выбрать наиболее оптимальный алгоритм расчета этого самого min-а.
В твоем же случае получается, что программист при написании программы, должен заранее знать какие действия наиболее ожидаемы и т.д. Он должен при этом не ошибится и т.д., при этом на самом деле он выполняет некую работу, которая легко формализуется, и легко может быть поручена компьютеру.
В твоем же случае получается, что программист при написании программы, должен заранее знать какие действия наиболее ожидаемы и т.д. Он должен при этом не ошибится и т.д., при этом на самом деле он выполняет некую работу, которая легко формализуется, и легко может быть поручена компьютеру.
С STL объём вчетверо меньше.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
это не постановка задачи, а описание класса, конечно... но в чем тут проблема - ума не приложу. Читаешь, пишушь... И еще, не понятно почему именно 4к и почему нельзя юзать С++? Это что, прога для ЦВК?
> Для оптимального перевычисления тебе придется сильно расширить свою формальную постановку задачи.
Не понял, зачем мне расширять постановку задачи?
В моей записи уже все есть, все остальные данные можно вытащить из контекста использования, статистики использования и т.д. В конечном итоге, это может быть даже просто настроено пользователем.
> А в самом тупом варианте задача решается просто для любых изменений массива.
Проблема в том, что для большинства задач тупой вариант не проходит.
Не понял, зачем мне расширять постановку задачи?
В моей записи уже все есть, все остальные данные можно вытащить из контекста использования, статистики использования и т.д. В конечном итоге, это может быть даже просто настроено пользователем.
> А в самом тупом варианте задача решается просто для любых изменений массива.
Проблема в том, что для большинства задач тупой вариант не проходит.
У меня возникло осущение, что тебе нужен исскуственный интеллект с телепатическими возможностями. Потому как формализовать то, что ты хочешь, может только он. Никакие языки не помогут.
просто нужен другой язык, чтобы формализовать эту задачу
попробуй на русском для начала
попробуй на русском для начала
> Я только хотел сказать, что ФЯП также далеки от требований реальных задач, как и C-подобные языки.
Прикольно. Ты понимаешь, что есть немало народу, чьи задачи ты вот так сразу обозвал "нереальными"?
> А такой уже есть?
Халявы хочется?
> Если такого нет, то ФЯП мне мало помогают.
Подумай ещё.
То, что ты назвал "условиями", очень легко представить в виде программы на чисто функциональном языке.
Если ещё расширить понятие "условий", то больше будут подходить языки логического программирования.
Вот, кстати, IMHO более интересная задача с той же идеей.
Текстовый редактор с подсветкой синтаксиса.
По-хорошему, его парсер должен быть неким надмножеством парсера языка, синтаксис которого подсвечивается.
Надмножеством, потому что наряду с корректными программами он обязан обрабатывать и некорректные (неоконченные).
В идеале парсер в компиляторе будет использовать тот же код.
То есть, имеем программу, у которой на входе текст, а на выходе - раскрашенный текст.
Теперь, такой парсер скорее всего не слишком быстро будет работать, так как проекты могут быть большие.
Однако нужно, чтобы при редактировании текста подсветка менялась мгновенно.
Реальные редакторы, конечно, халтурят, и потому глючат.
Идеальный редактор должен иметь общий парсер с компилятором и честно его использовать, но инкрементально.
Прикольно. Ты понимаешь, что есть немало народу, чьи задачи ты вот так сразу обозвал "нереальными"?
> А такой уже есть?
Халявы хочется?
> Если такого нет, то ФЯП мне мало помогают.
Подумай ещё.
То, что ты назвал "условиями", очень легко представить в виде программы на чисто функциональном языке.
Если ещё расширить понятие "условий", то больше будут подходить языки логического программирования.
Вот, кстати, IMHO более интересная задача с той же идеей.
Текстовый редактор с подсветкой синтаксиса.
По-хорошему, его парсер должен быть неким надмножеством парсера языка, синтаксис которого подсвечивается.
Надмножеством, потому что наряду с корректными программами он обязан обрабатывать и некорректные (неоконченные).
В идеале парсер в компиляторе будет использовать тот же код.
То есть, имеем программу, у которой на входе текст, а на выходе - раскрашенный текст.
Теперь, такой парсер скорее всего не слишком быстро будет работать, так как проекты могут быть большие.
Однако нужно, чтобы при редактировании текста подсветка менялась мгновенно.
Реальные редакторы, конечно, халтурят, и потому глючат.
Идеальный редактор должен иметь общий парсер с компилятором и честно его использовать, но инкрементально.
Да хоть сразу с четырьмя плюсами.
Сомневаюсь, что сильно поможет.
Трудность будет при разборе, сохранении программ и их интерпретации.
Примерно таким способом отлаживается разное достаточно умное железо.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Сомневаюсь, что сильно поможет.
Трудность будет при разборе, сохранении программ и их интерпретации.
Примерно таким способом отлаживается разное достаточно умное железо.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
эффективность алгоритма зависит только от того, как в будущем будет себя вести юзер! Т.к. обновление хипа производится "впрок". Естественно, если юзер будет вести себя так, что эта работа "впрок" будет всегда напрасной - мой метод не эффективен, если наоборот, будет вести себя так, что она будет постоянно использоваться, тогда прямой алгоритм будет тормозить. Короче, если в будущем M$ придумает новый набор классов System.Prophet, который будет гарантированно предсказывать поведение юзера в будущем, то тогда можно будет сделать и "идеальный" алгоритм
Потому, что языки программирования пока не умеют сами угадывать алгоритмы. Они в них или заложены заранее или их надо писать самому. Весь вопрос лишь в том, сколько сил надо потратить на перевод из человеческого понимания решения задачи в компьютерное, которое четко детерминировано. Я бы расположил ЯП в следующем порядке в плане удобства и близости человеку - специально созданный для решения задач данного типа язык, функциональный язык, императивный язык.
реальные редакторы обычно подсвечивают только лексемы, которые редко выходят за границы строки (кроме многострочных комментариев поэтому парсить обычно достаточно только одну строку...
По крайней мере за один блок обычно выходить не надо
мы же корректность программы проверяем, а не работоспособность
мы же корректность программы проверяем, а не работоспособность
ну, положим, они посложнее
но всё равно халтурят
но всё равно халтурят
Есть еще дополнение имен переменных и функции + вывод методов класса для быстрого ввода после . или -> и т.п.. Тут уже строчкой никак не обойдешься.
Автомат в твоей задаче очень простой, поэтому я верю, что она легко решается на низкоуровневом событийно-ориентированном языке.
А вот как будет на этом же языке решатся следующая задача?:
Есть лампочка, надо ее красить в разные цвета по следующим правилам:
1. Если стоит настройка, что визуальную индикацию делать не надо, то лампочка не горит (серый цвет)
2. Если связь установлена, то лампочка - зеленая
3. Связь оборвана - лампочка красная
4. Связь есть, но с ошибками - желтая.
5. Идет обмен через связь (или попытка обмена) - лампочка мигает.
Мигание - лампочка секунду горит (рисуется текущим цветом секунду не горит
(рисуется серым цветом).
Есть следующие свойства:
Визуальная индикация (есть/нет)
Связь (есть/нет)
Ошибки (есть/нет)
Обмен (есть/нет)
Есть следующие события:
Изменено свойство связь
Изменено свойство Ошибки
Изменено свойство Обмен
Изменено свойство Визуальная индикация
Прошла еще одна секунда
Надо написать программу, которые используя вышеперечисленные события, управляет цветом
лампочки.
А вот как будет на этом же языке решатся следующая задача?:
Есть лампочка, надо ее красить в разные цвета по следующим правилам:
1. Если стоит настройка, что визуальную индикацию делать не надо, то лампочка не горит (серый цвет)
2. Если связь установлена, то лампочка - зеленая
3. Связь оборвана - лампочка красная
4. Связь есть, но с ошибками - желтая.
5. Идет обмен через связь (или попытка обмена) - лампочка мигает.
Мигание - лампочка секунду горит (рисуется текущим цветом секунду не горит
(рисуется серым цветом).
Есть следующие свойства:
Визуальная индикация (есть/нет)
Связь (есть/нет)
Ошибки (есть/нет)
Обмен (есть/нет)
Есть следующие события:
Изменено свойство связь
Изменено свойство Ошибки
Изменено свойство Обмен
Изменено свойство Визуальная индикация
Прошла еще одна секунда
Надо написать программу, которые используя вышеперечисленные события, управляет цветом
лампочки.
На ФЯП несравнимо проще пишутся ПО (проблемно-ориентированные) ЯП, нежели на ИЯП.
Это решает и первую, и вторую задачу.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Это решает и первую, и вторую задачу.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
это совсем из другой оперы - отдельно готовится база идентификаторов (при загрузке проекта, например потом при парсинге отдельной строки подбирается в базе подходящий, пишется к нему комментарий (например, дефиниция или хелп а глюки бывают только если в базе подобрался элемент который ты прямо сейчас правишь. Сама база корректируется по результатам парсинга текущего текста до конца дефиниции (если щас правят именно ее, а не что-то еще)
> Потому, что языки программирования пока не умеют сами угадывать алгоритмы.
Забудем пока про int.
Но вот там была еще одна строка:
goodItems = Filter(items, {Item.Good});
Как можно заметить, вот это запись переводится в инкрементальную запись полностью формально, без учета всяких тонкостей.
Где здесь будет угадывание?
Забудем пока про int.
Но вот там была еще одна строка:
goodItems = Filter(items, {Item.Good});
Как можно заметить, вот это запись переводится в инкрементальную запись полностью формально, без учета всяких тонкостей.
Где здесь будет угадывание?
Книги тоже находятся в области копирайта.
Однако книгу ты можешь полностью просмотреть.
Причём безо всякого специального оборудования.
Сохранение высокоуровневости ЯП очень хорошо способствует получению быстрого кода --- лучше оптимизируется.
Кстати, код может быть хорошо покорёжен.
Разбирать код, состоящий из имён вида:
а) ``ll'', ``l1'', ``lll'', ``ll1'', ``l1l'' и т.д.;
б) ``O0'', ``OOO'', ``O0O'', ``OO0'' и т.д. ---
не так-то просто.
Далее действует обычная защита ключом.
Желательно, электронным.
Создавать такое дело можно на сервере, на лету.
Так, как, видимо, создаётся дискета от девятого плана.
Пришёл, ткнул, получил.
(Кстати, откуда я знаю, что ты не знаешь?
Здесь такие кадры попадаются --- ещё больше, чем ожидалось, знают.)
Для отладочной сборки можно собирать отдельно, по возможности, включая отладочные сведения.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Однако книгу ты можешь полностью просмотреть.
Причём безо всякого специального оборудования.
Сохранение высокоуровневости ЯП очень хорошо способствует получению быстрого кода --- лучше оптимизируется.
Кстати, код может быть хорошо покорёжен.
Разбирать код, состоящий из имён вида:
а) ``ll'', ``l1'', ``lll'', ``ll1'', ``l1l'' и т.д.;
б) ``O0'', ``OOO'', ``O0O'', ``OO0'' и т.д. ---
не так-то просто.
Далее действует обычная защита ключом.
Желательно, электронным.
Создавать такое дело можно на сервере, на лету.
Так, как, видимо, создаётся дискета от девятого плана.
Пришёл, ткнул, получил.
(Кстати, откуда я знаю, что ты не знаешь?
Здесь такие кадры попадаются --- ещё больше, чем ожидалось, знают.)
Для отладочной сборки можно собирать отдельно, по возможности, включая отладочные сведения.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Так я уже писал об этом. После любого изменения коллекции вызывается
goodItems = Filter(items, {Item.Good});
Ты скажешь, что это не оптимально. Но ведь ты никак не указал этого в своей постановке задачи. Ни один ЯП не сможет догадаться, что ты на самом деле хочешь. Может тебе как раз полностью нужно все пересчитывать по каким-либо соображениям.
goodItems = Filter(items, {Item.Good});
Ты скажешь, что это не оптимально. Но ведь ты никак не указал этого в своей постановке задачи. Ни один ЯП не сможет догадаться, что ты на самом деле хочешь. Может тебе как раз полностью нужно все пересчитывать по каким-либо соображениям.
> Вот, кстати, IMHO более интересная задача с той же идеей.
На первый взгляд она полностью аналогична моему примеру.
Здесь тоже необходимо от ФЯП постановки перейти, наиболее эффективным способом, к инкрементальной постановке задачи. Причем в ряде мест могут быть как чисто формальные переходы, так и не совсем. И вот только в этих "не совсем переходах" и хочется, чтобы программист помогал компилятору увидеть более эффективные переходы
На первый взгляд она полностью аналогична моему примеру.
Здесь тоже необходимо от ФЯП постановки перейти, наиболее эффективным способом, к инкрементальной постановке задачи. Причем в ряде мест могут быть как чисто формальные переходы, так и не совсем. И вот только в этих "не совсем переходах" и хочется, чтобы программист помогал компилятору увидеть более эффективные переходы
тоже с учетами... вообще, оптимизация добавления/удаления в коллекцию требует уточнения поведения юзера.
Например 2 стратегии: 1) список, добавление в конец, последовательный поиск 2) сортированный список, бинарный поиск
2 поведения юзера: А) FIFO или LIFO B) произвольное добавление и удаление
Проихводительность:
A1 -- O(1 A2 -- O(LOG(N B1 -- O(N B2 -- O(LOG(N
Например 2 стратегии: 1) список, добавление в конец, последовательный поиск 2) сортированный список, бинарный поиск
2 поведения юзера: А) FIFO или LIFO B) произвольное добавление и удаление
Проихводительность:
A1 -- O(1 A2 -- O(LOG(N B1 -- O(N B2 -- O(LOG(N
Точно.
А каким способом программист сможет помочь? Хорошей программой на специальном языке, который должен упрощать написание хороших в этом смысле программ.
А каким способом программист сможет помочь? Хорошей программой на специальном языке, который должен упрощать написание хороших в этом смысле программ.
> goodItems = Filter(items, {Item.Good});
> Ты скажешь, что это не оптимально. Но ведь ты никак не указал этого в своей постановке задачи.
Дык, это уже пошла отладка задачи
уточненная постановка задачи:
Что теперь не хватает для того, чтобы ЯП догался что от него хотят?
> Ты скажешь, что это не оптимально. Но ведь ты никак не указал этого в своей постановке задачи.
Дык, это уже пошла отладка задачи
уточненная постановка задачи:
#pragma Хочу, чтобы изменение коллекции goodItems делалось наиболее оптимальным способом
#pragma Побочного поведения у коллекции items и функции Item.Good нет.
goodItems = Filter(items, {Item.Good});
Что теперь не хватает для того, чтобы ЯП догался что от него хотят?
нужно указать, оптимальность в каких условиях
в любых - не получится, т.к. настолько оптимальной стратегии просто нет
в любых - не получится, т.к. настолько оптимальной стратегии просто нет
> тоже с учетами... вообще, оптимизация добавления/удаления в коллекцию требует уточнения поведения юзера.
уточнение: порядок коллекций goodItems и items меня не волнуют, я же не задавал условие сортировки для этих коллекций.
Поэтому ЯП порядок добавления может выбрать по своему усмотрению.
уточнение: порядок коллекций goodItems и items меня не волнуют, я же не задавал условие сортировки для этих коллекций.
Поэтому ЯП порядок добавления может выбрать по своему усмотрению.
А зачем нам "наиболее оптимальная"?
нас устроит почти оптимальная.
нас устроит почти оптимальная.
я правильно понял задачу, есть некая коллекция goodItems из которой надо время от времени удалять элементы которые исчезли в Items и имеют аттрибут Good и добавлять, если там появились новые?
Ну, например, слово "оптимальным".
Надо уточнить постановку задачи. Например, в коллекцию через разные промежутки времени с неизвестной частотой поступают сигналы о добавлении, удалении или изменении одного или нескольких элементов. Построить по уже постувшим сигналам достаточно оптимальную стратегию выполнения операций, исходя из предположения, что они не случайны.
Вот тут надо подумать.
Надо уточнить постановку задачи. Например, в коллекцию через разные промежутки времени с неизвестной частотой поступают сигналы о добавлении, удалении или изменении одного или нескольких элементов. Построить по уже постувшим сигналам достаточно оптимальную стратегию выполнения операций, исходя из предположения, что они не случайны.
Вот тут надо подумать.
ну вот и выбирай: одна стратегия дает в лучшем случае O(1 а в худшем O(N а другая - всегда дает O(log(N. Какая из них "почти оптимальнее"?
Пусть компилятор считает (мы ему такую опцию установили что вторая стратегия всегда эффективнее.
вообще, стратегии бывают байесовскими, бывают минимаксными (вторая - из их числа бывают прочие... Если компиляторы станут настолько умными что умогут их находить в общем случае - куча математиков останется без работы... 
Не верю что это поизойдет в ближайшие лет 20..
Не верю что это поизойдет в ближайшие лет 20..
В Java-е Jit-компиляция тоже уже некоторое время есть.
Знающий человек говорил, что спецификация Java не позволяет реализовать JIT-сомпиляцию, а те что есть идут с некоторыми нарушениями спецификации, а это не хорошо. (Если не веришь на слово, человек давал ссылку на стать,ю в которой это написано, могу спросить у нгего ссылку)
Спроси
мне интересно
мне интересно
Мне кажется, здесь был бы полезен единый формат, то есть, использовать XMLПричем тут XML, ты вообще знаешь что такое XML?
чисто мелкософтовская задумка.а ты думаешь MS это вместе с Oracle-ом разрабатывала?
я знаю, что такое XML
пишу на XSLT
и вижу здесь прямую связь - описать абстракции таким образом, чтобы было понятно всем языкам. Я не сказал, что здесь XML лучше подходит, я просто сказал, что не понимаю, какие тут преимущества bytecode
А при чем тут Оркл?
пишу на XSLT
и вижу здесь прямую связь - описать абстракции таким образом, чтобы было понятно всем языкам. Я не сказал, что здесь XML лучше подходит, я просто сказал, что не понимаю, какие тут преимущества bytecode
А при чем тут Оркл?
Хочешь сказать, что Sun нарушает собственную спецификацию?
http://wwws.sun.com/software/solaris/jit/
ps
И что мешает sun-у выпустить подкорректированную версию спецификацию, которой бы не противоречила JIT-компиляция.
http://wwws.sun.com/software/solaris/jit/
ps
И что мешает sun-у выпустить подкорректированную версию спецификацию, которой бы не противоречила JIT-компиляция.
> что спецификация Java не позволяет реализовать JIT-сомпиляцию, а те что есть идут с некоторыми нарушениями спецификации
а ты не перепутал?
наверное, речь шла про настоящую компиляцию
а ты не перепутал?
наверное, речь шла про настоящую компиляцию
херню напорол какую-то и замолчал
уж ответь, пожалуйста
уж ответь, пожалуйста
Ну, пять КА, и что?
Только писанины много.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Только писанины много.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
.Net возник на лснове проекта, который разрабатывался в каком-то исследовательском институте (название не помню там изначально была ориентация на JIT-компиляцию, поэтому здесь могут быть значительные различия с Java.
У java вроде как два режима, интерпретация и преобразование в байт-код
Не думаю, что в c# есть какие-то изменения, связанные с этим
jit для java тоже не дураки писали
к тому же все к чему прикладывает руку мелкософт - чаще всего пизженное тем или иным способом
ну и, в-третьих, я не говорил о реализации, я говорил о подходе
к тому же все к чему прикладывает руку мелкософт - чаще всего пизженное тем или иным способом
ну и, в-третьих, я не говорил о реализации, я говорил о подходе
DSL на 32 строки длиной не более 64 знаков, например, управление оборудованием терминала изобразить на Си++ сможешь?Соблюдайте правила форума, какое отношение твое изречение имеет к теме "Есть ли будущее у С#? "?
Чтение с пульта, разбор конструкций и вызов ОС.
Куда модераторы смотрят?
Контекст --- есть ещё такое слово.
Предлагаю ознакомиться со следующими исходниками начала 80-х:
1) ftp://ftp.taygeta.com/pub/Forth/Archive/ibm/forth.arc
2) ftp://ftp.taygeta.com/pub/Forth/Archive/ibm/fig86.lzh
Это подборка всяческих разностей: http://www.ultratechnology.com/forth0.htm
Железячная книга: http://www.ece.cmu.edu/~koopman/stack_computers/index.html
В последней упоминается процессор, ставший по недоразумению "ява".
О шитом коде:
http://www.figuk.plus.com/build/heart.htm
http://www.zetetics.com/bj/papers/moving1.htm
Где-то были замеры скоростей, но не вижу.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Предлагаю ознакомиться со следующими исходниками начала 80-х:
1) ftp://ftp.taygeta.com/pub/Forth/Archive/ibm/forth.arc
2) ftp://ftp.taygeta.com/pub/Forth/Archive/ibm/fig86.lzh
Это подборка всяческих разностей: http://www.ultratechnology.com/forth0.htm
Железячная книга: http://www.ece.cmu.edu/~koopman/stack_computers/index.html
В последней упоминается процессор, ставший по недоразумению "ява".
О шитом коде:
http://www.figuk.plus.com/build/heart.htm
http://www.zetetics.com/bj/papers/moving1.htm
Где-то были замеры скоростей, но не вижу.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
хоть идею напиши
Да, это всё по поводу JIT.
Один линуксоид сообщал, что он компилирует ок. мегабайта за 5 сек.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Один линуксоид сообщал, что он компилирует ок. мегабайта за 5 сек.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Молчал потому что читал весь этот зафлуженны тред.
Что ты подразумеваешь под словами "XML понятен всем языкам"? Текстовые файлы тоже всем понятны
Что ты подразумеваешь под словами "XML понятен всем языкам"? Текстовые файлы тоже всем понятны
ну и бред
назови мне язык, которому понятны текстовые файлы
теперь меня начинают мучать сомнения: ТЫ знаешь, что такое XML?
так, в двух словах ответь, для чего он используется в основном
назови мне язык, которому понятны текстовые файлы
теперь меня начинают мучать сомнения: ТЫ знаешь, что такое XML?
так, в двух словах ответь, для чего он используется в основном
Это то ты мне ответил?
На самом деле, я тоже много писал на XSLT.
тогда я не понимаю, откуда у тебя такие придирки
просто хочется поспорить?
никогда не видел книжки
"Java & XML"
"Perl & XML"
"C++ & XML" ?
Разве что Ассемблер & XML не бывает
так что идея абсолютно нормальная, по крайней мере с той стороны, с которой ты ее пытаешься критиковать
она не подходит только по производительности - собственно поэтому и не используется (я так думаю)
просто хочется поспорить?
никогда не видел книжки
"Java & XML"
"Perl & XML"
"C++ & XML" ?
Разве что Ассемблер & XML не бывает
так что идея абсолютно нормальная, по крайней мере с той стороны, с которой ты ее пытаешься критиковать
она не подходит только по производительности - собственно поэтому и не используется (я так думаю)
назови мне язык, которому понятны текстовые файлы
Ну, вопросом на вопрос не хорошо же. Мой ответ будет зависеть от того как ты ответишь на мой.
Вешаем на 4 ноги переключатели состояний, на 5-ую, которая тик, --- моргалку и инерционный гаситель (если у лампы есть инерция).
Разрисовываем состояния.
Менять состояния можно дубовым способом: как дёрнуло, сменить.
Если есть инерция --- сменить чуть позже, если нет дребезга.
Операции можно считать атомарными, от гонки ничего не зависит, разве что лампа на секунду позже зажгётся. Но это в пределах частоты дисретизации.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Разрисовываем состояния.
Менять состояния можно дубовым способом: как дёрнуло, сменить.
Если есть инерция --- сменить чуть позже, если нет дребезга.
Операции можно считать атомарными, от гонки ничего не зависит, разве что лампа на секунду позже зажгётся. Но это в пределах частоты дисретизации.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Если не секкрет, что ты пишешь на XSLT?
ответил
теперь ты
жду
Это всем.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Иерархическое меню
там запутанная такая система, куча технологий разных использутся (типа COM) - XSLT в том числе
там запутанная такая система, куча технологий разных использутся (типа COM) - XSLT в том числе
Да.....................А ты знаешь, что почти в первом абзаце спецификации XSLT написано, что оно ориентировано на отображение XML документов и не является универсальным XML преобразователем (это я говорю потому что тоже имел опыт применения XSLT не совсем для тех целей для которых оно преднозначено)
ну я применял его для тех целей, для которых оно предназначено XML->XML
но уже видимо из-за времени не улавливаю к чему ты это вообще говоришь
главное не это, главное, что я жду когда же ты мне ответишь на пост, на который пообещал ответить
у меня уже спортивный интерес
но уже видимо из-за времени не улавливаю к чему ты это вообще говоришь
главное не это, главное, что я жду когда же ты мне ответишь на пост, на который пообещал ответить
у меня уже спортивный интерес
по поводу текстовых файлов? ну так в любом языке текстовый файл считывается в две строчки
XML->XML
так вот не для любого такого преобразования
более того для очень широкого класса это выглядит криво
LOL
считывается, но не читается
понятней он от этого не становится
ответь мне в контексте XML
может ли текстовый файл быть понятным какому-либо языку также как понятен многим XML?
считывается, но не читается
понятней он от этого не становится
ответь мне в контексте XML
может ли текстовый файл быть понятным какому-либо языку также как понятен многим XML?
также как понятен многим XML
я вот об это тебя спрашивал, а ты не ответил
понятен, всмысле того, что XML может завертывать в себя объекты любой природы, а каждый из языков в силу своих возможностей их может по-разному развернуть
ты имеешь ввиду сериализацию в XML?
да
колбасу в XML ты вряд ли завернешь, а вот в бумагу без проблем
я сам не использоавл сериализацию, но по-моему она и без XML нормально работала
если ты ее засунешь в комп, так что она, к примеру, будет видна в виде файла, то завернешь
в общем, беседа несодержательна уже
ты ответишь насчет текстовых файлов или тебе нечего ответить?
а то я спать хочу
в общем, беседа несодержательна уже
ты ответишь насчет текстовых файлов или тебе нечего ответить?
а то я спать хочу
> Разрисовываем состояния.
В каком виде это делается? В ручную?
В каком виде это делается? В ручную?
а что есть модули для того, чтобы открывать объекты C++, сохраненные в XML, например, в Perl? если и сеть, то я всё равно не понимаю зачем тут нужен именно XML?
блин, как ты не поймешь без XML она может и работала, например в той же яве (как я ловко придерживаюсь темы )
но она работала для одного языка, а с XML она работает (в теории) везде
то чего не хватало для того, чтобы сериализация работала глобально - общий формат данных, а этот формат и есть XML
)но она работала для одного языка, а с XML она работает (в теории) везде
то чего не хватало для того, чтобы сериализация работала глобально - общий формат данных, а этот формат и есть XML
в виде файла
Фотку в XML? нахуй это нужно?
Вножную.
В уме. Переключатели почти независимы.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
В уме. Переключатели почти независимы.
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
нет таких модулей
мы изначально говорим о вещи, которая существует лишь в нашем воображении, если ты не понял
блин, почитай книжки, а то мы друг друга не понимаем в каких-то совсем простых вещах
в общем, чтобы все вернуть на свои места - напоминаю: речь шла о том, что bytecode помогает создавать объекты, которые могут использоваться разными языками. Я сказал, что не вижу, чем здесь может помочь bytecode. Здесь уж либо native, либо XML-подобное. Но bytecode не дает преимуществ
IMHO
вот и все, собственно
к чему ты тут привязался, я в результате так и не понял
мы изначально говорим о вещи, которая существует лишь в нашем воображении, если ты не понял
блин, почитай книжки, а то мы друг друга не понимаем в каких-то совсем простых вещах
в общем, чтобы все вернуть на свои места - напоминаю: речь шла о том, что bytecode помогает создавать объекты, которые могут использоваться разными языками. Я сказал, что не вижу, чем здесь может помочь bytecode. Здесь уж либо native, либо XML-подобное. Но bytecode не дает преимуществ
IMHO
вот и все, собственно
к чему ты тут привязался, я в результате так и не понял
на самом деле ты упускаешь главную деталь, для этой цели необходима спецификация сохранения объектов. В XML такой спецификации нет, он другое специфицирует. XML - это всего лишь набор договоренностей не более, но договоренности не о том что тебе хочется.
Фотку в XML? нахуй это нужно?
к примеру, ты хочешь посмотреть фотки сделанные цифровиком на своем новеньком телевизоре
но беда - телевизор не понимает RGB
догадайся - кто нам поможет?
конвертор из формата который у нас есть в тот который нам нужен
XML вообще ничего конкретного не описывает
а в чем проблема со спецификациями?
или ты хочешь сказать, что байт-код эти языки будут как открытую книгу читать, безо всяких спецификаций?
а в чем проблема со спецификациями?
или ты хочешь сказать, что байт-код эти языки будут как открытую книгу читать, безо всяких спецификаций?
XML это human readable язык, зачем нам читать фотку? а место она занимать будет при это наверно не мало
Я чего-то упустил?
Как организация кода относится к данным?
Будь он хоть в текстовом виде, данные от этого не изменятся?
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
Как организация кода относится к данным?
Будь он хоть в текстовом виде, данные от этого не изменятся?
---
Прогноз погоды: "Дождь над Иссык-Кулем сплошной пеленой..."
или ты хочешь сказать, что байт-код эти языки будут как открытую книгу читать, безо всяких спецификаций?CLR-код все языки.Net действительно легко читают
т.е. читают почти( за очень редким исключением) как свой
епт, ты делай какой-то парсер, который, к примеру пикселы заворачивает (на лету)
а телек их уже только разворачивать умеет, при чем ему не важно, что ему суют, фотку или видео или спутниковый канал
в этом вся фишка XML
а ты ее, как я вижу не просек, когда книжку читал
вот из-за такой невнимательности люди и выбирают c# вместо Java, а Windows вместо Linux
обидно, что люди не умеют включать голову
хотя их этому многие годы обучают
но они продолжают слушать, что скажет дядя билли
а телек их уже только разворачивать умеет, при чем ему не важно, что ему суют, фотку или видео или спутниковый канал
в этом вся фишка XML
а ты ее, как я вижу не просек, когда книжку читал
вот из-за такой невнимательности люди и выбирают c# вместо Java, а Windows вместо Linux
обидно, что люди не умеют включать голову
хотя их этому многие годы обучают
но они продолжают слушать, что скажет дядя билли
блин, ребята, я спать пошел
хватит уже херней страдать
это просто флуд
к текстовому файлу непонятно с какого конца подойти, а к XML всегда понятно и этот подход можно сделать уникальным
хотя можно все сделать в текстовых файлах и жить вечно
изобрести кучу форматов, типа виндовского уебищного .ini, который потом хрен проанализируешь чем-нибудь
в общем - НИКАКОЙ РАЗНИЦЫ
на хуй XML
всем спокойной ночи
хватит уже херней страдать
это просто флуд
к текстовому файлу непонятно с какого конца подойти, а к XML всегда понятно и этот подход можно сделать уникальным
хотя можно все сделать в текстовых файлах и жить вечно
изобрести кучу форматов, типа виндовского уебищного .ini, который потом хрен проанализируешь чем-нибудь
в общем - НИКАКОЙ РАЗНИЦЫ
на хуй XML
всем спокойной ночи
Личные оскорбления - последнее что могут сделать тупые люди. Я на твои посты больше не отвечаю.
бля
извини меня пожалуйста, но я тебя оскорблять не собирался и не собираюсь
я просто хотел указать на некоторые ошибки, как ты мне хотел указать на мои
не вижу принципиальной разницы
забей
вот на критику обижаются точно глупые люди
извини меня пожалуйста, но я тебя оскорблять не собирался и не собираюсь
я просто хотел указать на некоторые ошибки, как ты мне хотел указать на мои
не вижу принципиальной разницы
забей
вот на критику обижаются точно глупые люди
Зачему, что формально задача описывается одной функцией:
Все переходы между событиями однозначно восстанавливаются по данному формальному описанию.
И мне не понятно почему эти вычисления программист должен производить сам.
Color LampColor
{
get
{
if (!IsVideoIndicate)
return Color.Gray;
if (IsBlinking && IsDarkPeriod)
return Color.Gray;
if (!IsConnect)
return Color.Red;
if (IsErrors)
return Color.Yellow;
return Color.Green;
}
}
Все переходы между событиями однозначно восстанавливаются по данному формальному описанию.
И мне не понятно почему эти вычисления программист должен производить сам.
Оставить комментарий
markmsk
Интересено узнать мнение про этот язык.Перспективно ли его изучение, а так же мнение про точку НЕТ.