Balancer: Все сообщения за 15 Марта 2005 года

Zeus>Где там у тебя БС? [»]

БС для меня куда более важна, чем для тебя

Так вот, резюме - БС от этого не страдает. У кого-то может пострадать ЧС (как же! престижность падает! голый пластик!), но меня ЧС может только достать когда пыльным мешком по голове из-за угла

•  3
•  инфо
•  инструменты
• Ответить на сообщение

Zeus> Неужели кто-то еще спичками пользуется для зажигания газа на кухне?? [»]

Я пользуюсь постоянно
Покупаю прямо во дворе в продуктовом магазинчике.

Кстати, если кто не в курсе, старый деревенский опыт - спички в туалете "освежают" воздух гораздо эффективнее любого освежителя. Т.к. не забивают запах, а SO2 химически связывает пахучие соединения

•  инфо
•  инструменты
• Ответить на сообщение

Balancer>> Каждый поощряет свои глюки Пример с поощрением использования в Паскале имеющихся имён смотри выше
Zeus> Это НЕ поощрение использования повторяющихся имен. Если писать нормально и по правилам, а не после книжки "ххх для чайников".

Язык делает менее удобным введение новых имян? Значит поощряет использование имеющихся. Точка.

Zeus> Короче, ты все еще утверждаешь, что "сишный" (символьный - вообще-то, именно с этого разговор начался, т.е. с "орфографии") синтаксис провоцирует меньше ошибок, чем "словарный"?

Я утверждаю, что "символьный" синтаксис в разумных пределах оптимальнее "словарного". Противоположность "словарному" - это не Си, и даже не Perl. Это - APL, например. Вот Си находится как раз между "крайними символьными" и "крайними словарными" языками и, ИМХО, близок к оптимуму.

Balancer>> Глупости. Ни в одном сложном проекте ты заранее не распишешь и малой доли нужных переменных Просто возможностей твоего мозга не хватит. Так что ты тут явно преувеличиваешь
Zeus> Что-то ты уводишь в сторону. Причем здесь проект, когда это решается на уровне функции? Именно о ней речь.

Ещё раз скажу. Не знаю чем, но Паскалевский синтаксис провоцирует написание гиперимперативных программ. Паскалевцы не любят проводить декомпозицию. Более того, видел пару раз, как один и тот же человек писал на Си вполне факторизованные программки, с функциями, обычно, влезающими в пределы экрана, а на Паскале лепил простыни по 8 экранов. Я не знаю, с чем это связано, но это - мои наблюдения.

Zeus> Вот "проецировать не надо" Я - не начну. Потому что понимаю, зачем это нужно (т.е. не нужно )

Нет, давай уже определимся. Тебе, как классическому ЧЛ, нужно ставить очень жёсткие начальные условия, а то в споре вы "вилять" начинаете

Ты утверждаешь, что для тебя лично паскалевский синтаксис лучше? Так я не спорю! Дело вкуса. Но ты, вроде бы, перед этим пытался обощать, что этот синтаксис вообще лучше? Вот с этим я буду спорить. Поэтому твоё личное понимание в этом споре роли не играет. Важно, как и что понимает среднестатистический программист.

Zeus> Вообще, меня бесит, когда при чтении текста я натыкаюсь на какую-то новую переменную. Одно дело - глянул в декларации, что да как, другое - рыскать по тексту в глубине операторов, где там она вводится, какого типа, где у нее scope...

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

Zeus> Кстати, по твоей задаче (большому проекту) есть еще одна практическая тонкость. Даже очень большой проект я всегда отлаживал "по живому" (ну, не считая совсем новых модулей или алгоритмов, но это редко, мы же о мелких изменениях говорим). На порядок большая скорость компиляции и сборки позволяет комфортно работать сразу с проектом.

Не знаю. У меня вышеупомянутый проект, если без ошибок, собирается за 2..4 секунды. Другое дело, что, как я уже писал, сам запуск сервера - секунд тридцать. Запуск клиента - пара минут. А потом ещё тестирование... Но к языкам программирования непосредственно это не относится. Если проект сделать на Дельфи, а не на Яве, быстрее клиент запускаться не станет

Zeus> Ну и в чем синтаксис "Си" больше поощряет декомпозицию?

Не знаю. М.б. тем, что там проще декларация функций и begin/end писать не нужно. Соответственно - меньше лени Но факт есть факт - по моим наблюдениям в равных условиях, программы на Си более декомпозированы. Даже из соображений "лени мозга". В Си ввести новую функцию - это набить десяток-другой символов. В Паскале - и писать нужно больше, как я уже сказал, и, главное, ещё о твоих декларациях переменных думать придётся А это всё снижает привлекательность введения новых функций.

Zeus> Не локальных переменных, а локальных "блоков", а еще точнее - просто определения локальных переменных в тексте функции. Пользу я вижу, но вижу и вред. "Польза" позволяет быстрее кодировать, но затрудняет все остальные операции и к тому же приводит к умственной лени.

Когда что либо позволяет быстрее кодировать, то высвободившееся время можно потратить на раздумья над проектом. А когда кодируешь медленнее, то и лишнего времени меньше. Не зря принцип гласит - "машина должна работать, человек - думать". Так что пусть лишнюю писанину твою возьмёт на себя компилятор. А ты - будешь думать

Zeus> Идиот - наверняка, но мы же не об идиотах говорим

Но и не о тебе же См. выше. Среднестатистический программист по твоим определениям - идиот. Так что, наверное, мы говорим об идиотах

Zeus> В основном потому что средний уровень квалификации на них пишущих заметно ниже - по историческим, опять же, причинам.

Ой, не знаю... Самый низкий уровень качества программ, тогда, на VB должен быть. А он примерно на одном уровне с Дельфи

Zeus> Вот запрет перекрытия - именно с умом, а не прихоть.

Не знаю я такого ума И очень рад, что в Java такого ограничения нет

>А вот скажи, исключение указателей в Джаве и вообще многих современных языках - это "с умом" или как?

Какие, нафиг, исключение, родной?? Да в Java всё на указателях! Просто они там подразумеваются неявно. Если грубо, то int, double, float и т.п. - передаются значением. Но - только они. А, например, Integer, Double, Float - это уже полноценные объекты и передаются всегда указателями.

В общем, после перехода на Java, я ещё ни разу не столкнулся с проблемами нехватки указателей... Вот чего не хватало, пока с Reflection не столкнулся - так это вызова функций по имени, заданном в строке.

Balancer>> Остаётся удивиться, где он этот Оберон [»]
Zeus> Там же, где, скажем, BeOS. Цюрихский (или какой там) университет - это все же не Sun по ресурсам. […

Дальше »»»

•  инфо
•  инструменты
• Ответить на сообщение

BrAB> Пасибо за совет про боковины

Кстати, после отклеивания резины оставшийся пластик может болтаться (прижим ослабевает). Левая боковина у меня и так крепко держится, а вот под правую сперва подкладывал сложенную втрое бумажку, а потом посадил на микрокаплю клея. Если понадобится в сервис нести - то отклеить легко. А так - уже больше полугода держится

BrAB> Вопрос можно? что за карта москвы? а то у меня только схема метро есть [»]

Есть три популярных карты. Устаревшие PalmGIS и LaserMap. Я предпочитал LaserMap. Она побыстрее, карта Москвы с домами под неё подробнее, поиск удобнее.

Нынешний фаворит - PocketGPS. Она помедленнее, чем LaserMap, но зато помнит при открытии последнее место, где были при выходе, что очень удобно на 2210 с его потерей файлов, открытых с карточки при выключении. Карты при этом падают, но в LaserMap, загружающейся, хоть и 12 секунд, потом приходится искать нужное место снова, а в PocketGPS, хоть и 20 секунд идёт загрузка, зато точно в то место, на котором были при закрытии программы.

Скриншоты - Карта Москвы и области PocketGPS Pro Moscow для КПК: копии экранов



В незаконном виде её можно найти в eMule 19Мб...

•  инфо
•  инструменты
• Ответить на сообщение

Zeus> Демагогия. Устал отвечать.

Я-то устал уже несколько дней назад

Zeus> Имхо, нет, перебор. Но дело даже только и не столько в самих символах, сколько в гибких правилах их конструирования. Которые имеют (или рождают) кучу тонкостей (вроде различения а++ и ++а) и порождают кучу неявных ошибок.

В (a++ + ++a) в рамках синтаксиса нет никакой неопределённости. Это обсуждалось уже не раз. Другое дело, что как выяснилось, в рамках стандарта Си/Си++ прописана неопределённость этого выражения. Судя по всему, ради возможности лучшей оптимизации старых компиляторов. Сейчас же эта проблема уже не актуальна и все новые языки трактуют это выражение так, как положено из его синтаксиса и как ожидается по элементарной логике.

Zeus> Еще важнее, как и на чем этого "среднестатистического программиста" учат. А ситуация здесь просто удручающая. Вот и приходится писать языки в угоду чайникам, с поощрением заплаточного стиля

Т.е. ты уже договорился до того, что введение локальных областей видимости в Си было сделано ради чайников?

>постоянной отладки и т.п.

Это почти столь же смешно

>Тогда как при нормальном подходе на отладку уходит не больше времени, чем на проектирование.

Этот "нормальный подход" годится только для строго формализуемых решений или задач уровня квадратного уравнения. Посмотрю я на такой подход при любой задаче хотя бы уровня аркадной компьютерной игры Когда 9/10 условий задачи формируется по результатам разработки. Любая крупная задача имеет массу обратных связей в процессе разработки и решаются они исключительно итеративно.

>Если бы подход изначально был инженерным, таких монстров как Си и Джава и не родилось бы.

Ну да. Ну да...

Balancer>> Не знаю. У меня вышеупомянутый проект, если без ошибок, собирается за 2..4 секунды. Другое дело, что, как я уже писал, сам запуск сервера - секунд тридцать.
Zeus> А что так долго? Из-за Джавы небось?

Долго что? Сборка? Хочешь сказать, что Дельфи проект в 500 файлов и в 2.5Мб компилирует быстрее? Очень сомневаюсь

Запуск? Извини, там только из БД читается под 50 тыс. записей, для каждой из них формируются поля объектов и т.п. В игре только активных мобов в стандартном мире около 30 тыс, каждый из которых - продвинутый интерактивный объект

Кроме того, можно, ведь, и в лоб сравнить скорости готовых решений на Дельфи и на Java. Хочешь - потестируемся. Ты выбираешь ресуроёмкую задачу и присылаешь exe-шник и алгоритм. Я такую же делаю на Java и выкладываю .class - сравним скорость работы

>> Но к языкам программирования непосредственно это не относится. Если проект сделать на Дельфи, а не на Яве, быстрее клиент запускаться не станет
Zeus> Вот это как раз спорно Ну, клиент может быть, вернее, это малосущественно, а сервер-то чего?

А сервер с того, что даже на чистой математике Дельфи не принципиально быстрее Java, а у нас тут лимитирует даже не математика, а работа с БД, формирование объектов и т.п...

Zeus> То есть - по соображениям откровенно детским. И этому надо потакать??

Опять, определись - мы говорим о нас с тобой персонально (и тогда спор бессмысленный, т.к. у каждого свои предпочтения) или о вероятности создания ошибок среднестатистическим программистом? Если второе, то соображения эти не "откровенно детские", а самые что ни на есть практичные.

Zeus> Щаз! Оно пойдет на долгую и мучительную отладку, а не на "раздумья". К тому же, время именно кодирования тут различается несущественно.

Существенно.

Zeus> Он не идиот, он жертва прогресса Его просто не доучили...

Какая нам разница с точки зрения языка?

Zeus> А там, где на Дельфи (или даже на VB, хотя мне не попадалось) пишут профессионалы - получается не хуже.

А что они забыли на том и другом? Вообще, где примеры профессионального (пусть хотя бы внешне) программирования на Дельфи? Ну, Total Commander. Ну, JAJC (правда, уже умерший и так и не избавившийся от ряда глюков). Что ещё? А вот на счёт Си - тут ка краз пример скорее обратный Т.е. большинство профессиональных проектов, я уже не говорю про все популярный ОС, написаны на Си/Си++...

Zeus> Вот именно что неявно. То есть отобрали у программистов цацку и сделали жесткое правило. Об этом я и говорю. Это общая тенденция, только что-то поздно доходит.

Общая тенденция - отбирать у программиста опасные средства и поручать работу с ними компилятору. Но вот от локальных областей видимости что-то отказываться и не собираются

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

Впрочем, это уже совсем мутная тема

Zeus> Вот именно! Но такой сущности - "указатель" - в языке нет.

Здрасьте! Если "указатели" обозвали "ссылками" - их теперь в языке нет?

Zeus> Ну и у Оберона есть своя ниша, и используется он. Только его ниша больше пересекается с существующими "общеупотребительными" языками (точнее сказать, полностью их охватывает), это все же "классический" язык.

Ну и те же Ruby или Python - вполне "классические" (т.е. императивные в твоём понимании?) языки.

>И как всегда в таких случаях, лучше уж выучить пусть и худший, но коммерчески используемый язык.

Это ты уже причины со следствием путаешь. Ruby или Python не были изначально "коммерчески используемыми". Но - стали потом. почти вытеснив во многих местах Perl и bash и потеснив PHP с Java.

Собственно, на sourceforge сегодня проектов на Python больше, чем на VB или Дельфи!

Да что там говорить, там десятки проектов на Eiffel, Lisp, Tcl... Но где там Оберон? Нет ни одного проекта...

Zeus> Да и не в Обероне, в общем-то, дело. Перечисленные языки тож…

Дальше »»»

•  инфо
•  инструменты
• Ответить на сообщение

Zeus> A маршрут по дорогам они прокладывают? Предупреждают заранее голосом, если с GPS в машине?

PocketGPS именно так и делает. Голосом инструктирует "через 300 метров повортот направо... через 200 метров... через 10 метров..." При чём ещё может в онлайне подгружать информацию о пробках и прокладывает маршрут с учётом их. Естественно, в прокладке маршрутов учитываются правила движения, односторонность некоторых проездов, развязки и т.п.

Zeus> И еще даже для меня важнее: есть ли карта (вернее, программа), которая позволяет вводить непосредственно координаты, причем не только географические, но и UTM? И вообще-то желательно трек писать Можно даже без карты, просто функционально простенький GPS... [»]

Треки пишут очень многие. Про координаты недопонял. В смысле - проложить маршут к заданным координатам? Наверняка есть, но не разбирался, т.к. всё равно GPS нет... да и машины тоже

•  1
•  инфо
•  инструменты
• Ответить на сообщение