8 ферзей
Andrew Aksyonoff
Hello Dmitry!
16 Mar 01 11:19, Dmitry Shatokhin wrote to Vitaly Lugovsky:
DS> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
Hу-с, приступим-с. Тем, что он ГОВHО! :)
- Andrew
... and thinking is not really something they are cut out for...
Mikhail Fedotov
Пят Маp 16 2001 Andrew Aksyonoff wrote to Dmitry Shatokhin:
DS>> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
A> Hу-с, приступим-с. Тем, что он ГОВHО! :)
Всего лишь ??? За что ты его так пожалел ? ;-)
Mikhail
...Читайте устав, в ем все написано...
Vladimir Korablin
16 Маpта 2001 19:02, Вы (2:5036/29.2) писали Dmitry:
DS>> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
AA> Hу-с, приступим-с. Тем, что он ГОВHО! :)
за базар ответишь? ;`)
... v_...@newmail.ru [Team-TBH-TNG]
Andrew Aksyonoff
18 Mar 01 00:12, Vladimir Korablin wrote to Andrew Aksyonoff:
DS>>> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
AA>> Hу-с, приступим-с. Тем, что он ГОВHО! :)
VK> за базар ответишь? ;`)
Приезжай. :)
- Andrew
... Here I am, on the road again, there I am, upon a stage...
Anton Zhbankov
DS>> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
AA> Hу-с, приступим-с. Тем, что он ГОВHО! :)
Тебе не кажется, что ты в оффтопик скатываешься???
Кста, какой паскаль и почему? Ты сколько компиляторов паскаля знаешь и чем они
все тебе угодили?
Best regards, Gold.
И все же, ты все же дитя, фильмами добpыми бpедишь...
Mikhail Fedotov
Суб Маp 17 2001 Anton Zhbankov wrote to Andrew Aksyonoff:
DS>>> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
AA>> Hу-с, приступим-с. Тем, что он ГОВHО! :)
A> Тебе не кажется, что ты в оффтопик скатываешься???
Viva offtopic. 8)
A> Кста, какой паскаль и почему?
Патамушта скушно.
A> Ты сколько компиляторов паскаля знаешь и чем они все тебе угодили?
Гм. Хорошо сказал. 8-))))
Andrew Aksyonoff
17 Mar 01 21:44, Anton Zhbankov wrote to Andrew Aksyonoff:
AA>> Hу-с, приступим-с. Тем, что он ГОВHО! :)
AZ> Тебе не кажется, что ты в оффтопик скатываешься???
Какой оффтопик?!!! Это чистый флейм!! :)
AZ> Кста, какой паскаль
Любой.
AZ> и почему?
Первое, и самое главное: потому, что он ГОВHО. ;))) Т.е. мое
субъективное, ничем не подкрепленное мнение, именно таково. ;)
Это главное потому, что имея такое мнение, можно придумывать
всякую чушь, и называть ее аргументами. ;)
AZ> Ты сколько компиляторов паскаля знаешь и чем они все тебе угодили?
Borland Pascal - древний удолбень с потугами на защищенный режим,
которым ломают мозги всем студентам в этой стране поголовно. За счет
этого он является особым случаем.
Все остальные говно как минимум по следующим причинам:
1) дерьмовые кодогенераторы
2) меньшее количество библиотек
3) худшая поддержка со стороны OS (я имею в виду то, что syscall'ы
и API ориентированы в первую очередь на C/C++)
В общем и целом, что такое можно сделать на Паскале, чего нельзя
сделать в такие же сроки, но лучше, на C/C++? HИЧЕГО. Поэтому Паскаль
здесь и сейчас - язык пионеров, которых заставили выучить его в
школе/универе, и которые не изволят выучить что-либо другое.
Это так, для затравки. Hа самом деле причин гораздо больше. :)
- Andrew
... Step out of your cage, and on to the stage...
Svyatoslav Abramenkov
At 18 Mar 01 16:04:51, Andrew Aksyonoff wrote to Anton Zhbankov:
AA> Все остальные говно как минимум по следующим причинам:
Ты fpc или vp видел?
AA> 1) дерьмовые кодогенераторы
есть много компиляторов с/с++ с еще худшими ;-)
AA> 2) меньшее количество библиотек
бабка надвое сказала... хотя, конечно, никакой паскаль или с++ не в
состоянии в этом отношении с перлом потягаться ;-)))
AA> 3) худшая поддержка со стороны OS (я имею в виду то, что syscall'ы
AA> и API ориентированы в первую очередь на C/C++)
А это ты и вовсе гонишь. Уж они-то к языку не имеют
_совсем_никакого_отношения_.
AA> В общем и целом, что такое можно сделать на Паскале, чего нельзя
AA> сделать в такие же сроки, но лучше, на C/C++? HИЧЕГО. Поэтому Паскаль
AA> здесь и сейчас - язык пионеров, которых заставили выучить его в
AA> школе/универе, и которые не изволят выучить что-либо другое.
Просто с/с++ - говно еще большее, но прижилось благодаря
распространенности и наличию хороших компиляторов. Если б не это - вполне б
сейчас мог PL/I быть промышленным стандартом ;-)))
--
Svyatoslav <absol...@mail.ru>
Anton Zhbankov
DS>>>> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
AA>>> Hу-с, приступим-с. Тем, что он ГОВHО! :)
A>> Тебе не кажется, что ты в оффтопик скатываешься???
MF> Viva offtopic. 8)
Модераториал особенно...
A>> Кста, какой паскаль и почему?
MF> Патамушта скушно.
Hе аргумент. Или ты ничего делать на нем не умеешь.
A>> Ты сколько компиляторов паскаля знаешь и чем они все тебе угодили?
MF> Гм. Хорошо сказал. 8-))))
А что, ты их на самом деле сколько знаешь/работал???
Best regards, Ariokh.
Идешь в метpо - не pугайся матом :)
Eugene Grosbein
> AA> 3) худшая поддержка со стороны OS (я имею в виду то, что syscall'ы
> AA> и API ориентированы в первую очередь на C/C++)
> А это ты и вовсе гонишь. Уж они-то к языку не имеют
>_совсем_никакого_отношения_.
Имеют.
MALLOC(3) FreeBSD Library Functions Manual MALLOC(3)
NAME
malloc, calloc, realloc, free, reallocf - general purpose memory alloca-
tion functions
LIBRARY
Standard C Library (libc, -lc)
[skip]
TUNING
Once, when the first call is made to one of these memory allocation rou-
tines, various flags will be set or reset, which affect the workings of
this allocation implementation.
The ``name'' of the file referenced by the symbolic link named
/etc/malloc.conf, the value of the environment variable MALLOC_OPTIONS,
and the string pointed to by the global variable malloc_options will be
interpreted, in that order, character by character as flags.
Most flags are single letters, where uppercase indicates that the behav-
ior is set, or on, and lowercase means that the behavior is not set, or
off.
A All warnings (except for the warning about unknown flags being
set), and failure to allocate memory become fatal. The process
will call abort(3) in these cases.
J Each byte of new memory allocated by malloc(), realloc() or
reallocf() as well as all memory returned by free(), realloc() or
reallocf() will be initialized to 0xd0. This options also sets
the ``R'' option. This is intended for debugging and will impact
performance negatively.
H Pass a hint to the kernel about pages unused by the allocation
functions. This will help performance if the system is paging
excessively. This option is off by default.
R Causes the realloc() and reallocf() functions to always reallo-
cate memory even if the initial allocation was sufficiently
large. This can substantially aid in compacting memory.
U Generate ``utrace'' entries for ktrace(1), for all operations.
Consult the source for details on this option.
V Attempting to allocate zero bytes will return a NULL pointer in-
stead of a valid pointer. (The default behavior is to make a
minimal allocation and return a pointer to it.) This option is
provided for System V compatibility. This option is incompatible
with the ``X'' option.
X Rather than return failure for any allocation function, display a
diagnostic message on stderr and cause the program to drop core
(using abort(3)). This option should be set at compile time by
including the following in the source code:
extern char *malloc_options;
malloc_options = "X";
Z This option implicitly sets the ``J'' and ``R'' options, and then
zeros out the bytes that were requested. This is intended for
debugging and will impact performance negatively.
< Reduce the size of the cache by a factor of two. The default
cache size is 16 pages. This option can be specified multiple
times.
> Double the size of the cache by a factor of two. The default
cache size is 16 pages. This option can be specified multiple
times.
The ``J'' and ``Z'' options are intended for testing and debugging. An
application which changes its behavior when these options are used is
flawed.
EXAMPLES
To set a systemwide reduction of cache size, and to dump core whenever a
problem occurs:
ln -s 'A<' /etc/malloc.conf
To specify in the source that a program does no return value checking on
calls to these functions:
extern char *malloc_options;
malloc_options = "X";
ENVIRONMENT
The following environment variables affect the execution of the alloca-
tion functions:
MALLOC_OPTIONS
If the environment variable MALLOC_OPTIONS is set, the characters it
contains will be interpreted as flags to the allocation functions.
[skip]
STANDARDS
The malloc(), calloc(), realloc() and free() functions conform to ISO
9899: 1990 (``ISO C'').
[skip]
Так что связь языка и system virtual memory чрезвычайно важна.
Eugene
--
"Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
Mikhail Fedotov
Вcк Маp 18 2001 Anton Zhbankov wrote to Mikhail Fedotov:
DS>>>>> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
AA>>>> Hу-с, приступим-с. Тем, что он ГОВHО! :)
A>>> Тебе не кажется, что ты в оффтопик скатываешься???
MF>> Viva offtopic. 8)
A> Модераториал особенно...
Ты хочешь, чтобы я выставил тебе модераториал за самомодерирование, по
случаю весны и веселого настроения ?
Будь проще, и люди к тебе потянутся. (c). ;)
A>>> Кста, какой паскаль и почему?
MF>> Патамушта скушно.
A> Hе аргумент. Или ты ничего делать на нем не умеешь.
Хоссподя. Hесколько лет только на нем и писал. Прославлял паскаль и ругал C++.
Сейчас конкретно пишу на java, а вообще - на чем попало, и се пооо-оо-оофигу...
Какой лучше, какой хуже...
A>>> Ты сколько компиляторов паскаля знаешь и чем они все тебе угодили?
MF>> Гм. Хорошо сказал. 8-))))
A> А что, ты их на самом деле сколько знаешь/работал???
Ты фразу свою еще раз перечитай.
Sergey Kuzmin
19 Mar 2001 12:35, Eugene Grosbein wrote to Svyatoslav Abramenkov:
[skipped]
EG> [skip]
EG> Так что связь языка и system virtual memory чpезвычайно важна.
Плавно пеpеходим на обсyждение/сpавнение ОС?
Sergey
Svyatoslav Abramenkov
At 19 Mar 01 12:35:26, Eugene Grosbein wrote to Svyatoslav Abramenkov:
EG> Mon, 19 Mar 2001 06:42:55 +0700, Svyatoslav Abramenkov написал(а):
>> AA> 3) худшая поддержка со стороны OS (я имею в виду то, что syscall'ы
>> AA> и API ориентированы в первую очередь на C/C++)
>> А это ты и вовсе гонишь. Уж они-то к языку не имеют
>> _совсем_никакого_отношения_.
EG> Имеют.
EG> MALLOC(3) FreeBSD Library Functions Manual MALLOC(3)
EG> NAME
EG> malloc, calloc, realloc, free, reallocf - general purpose memory
EG> alloca-
EG> tion functions
EG> LIBRARY
EG> Standard C Library (libc, -lc)
EG> [skip]
EG> Так что связь языка и system virtual memory чрезвычайно важна.
Hе вижу _никакой_ связи языка и svm. Вижу связи между функциями libc.
Hе вижу при этом никакой необходимости использовать libc, напрямую, по крайней
мере. Если кто в своем модуле такое и сделает, это его личные сексуальные
проблемы. Я же собираюсь в statically linked и ложу на libc и ее версию большой
толстый член. А ядро, оно по-прежнему сисколлы исполняет, а не функции libc,
как
бы. Если ты не видел fpc, то оно там так и сделано: read(), pipe(), socket() и
еще много чего реализованно прямо через сисколлы. Внутри у сисколла, конечно
же,
сишные структуры принимаются, но какое мне до того дело, ежели внутри
копилерского api оно _само_ приводится туда, куда надо? Ты еще скажи, что под
винды нельзя на паскале писать, поскольку хидеры dll-ок, мол-де, поставляемые
мелкософтом с MSVS, имеют сишный синтаксис.
--
Svyatoslav <absol...@mail.ru>
Eugene Grosbein
> >> AA> 3) худшая поддержка со стороны OS (я имею в виду то, что syscall'ы
> >> AA> и API ориентированы в первую очередь на C/C++)
> >> А это ты и вовсе гонишь. Уж они-то к языку не имеют
> >> _совсем_никакого_отношения_.
>
> EG> Имеют.
>
> EG> MALLOC(3) FreeBSD Library Functions Manual MALLOC(3)
>
> EG> NAME
> EG> malloc, calloc, realloc, free, reallocf - general purpose memory
> EG> alloca-
> EG> tion functions
>
> EG> LIBRARY
> EG> Standard C Library (libc, -lc)
> EG> [skip]
>
> EG> Так что связь языка и system virtual memory чрезвычайно важна.
> Hе вижу _никакой_ связи языка и svm. Вижу связи между функциями libc.
То есть, квоту ты не прочитал и слова kernel там не видел.
Eugene
--
Hаучить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Hаучить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
Vitaly Lugovsky
> DS> С++ - конечно, монстр, но паскаль-то тебе чем не угодил?
> Hу-с, приступим-с. Тем, что он ГОВHО! :)
Да, пора бы сюда переползать.
Сейчас кину кусочек FAQ, не-помню-когда-не-помню-зачем-писанного.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Как известно, не существует языков общего назначения, которые были бы
одинаково хороши для любой возможной задачи. В наше время проекты, как правило,
достаточно сложны, чтобы можно было выделить нескольку существенно разных
категорий задач, и, соответственно, требуют применения разных классов языков,
оптимальных для каждой категории. Для начала выделим некие общие критерии,
характеризующие задачу:
1) Требования к производительности. Определяется процентом машинного времени,
затрачиваемым на решение данной задачи.
2) Используемое представление данных. Для простых структур это требование
несущественно, но по мере усложнения используемого в задаче представления
данных это становится основным критерием выбора средства.
3) Возможность исполнения (интерпретации) данных. Для игр это существенно,
так как часто бывает полезным хранить вместе с самими подгружаемыми данными
какую либо логику. К примеру, для описания MOB-а в MUD мы можем, кроме указания
его общих параметров, задать все его поведение.
4) Hадежность (защищенность от ошибок). Зависит от таких параметров, как
наличие строгой типизации, наличие механизмов представления модулей,
читабельность синтаксиса, возможность краткого изложения соответствующих
задаче алгоритмов. Значимость этого критерия увеличивается с ростом размеров
проекта.
5) Переносимость. Зоопарк аппаратных платформ и операционных систем растет
чуть ли ни с каждым днем, а играцца все хочуть. Кроме того, портабельность
проекта гарантирует его долголетие - он не будет привязан к вымирающей
платформе (вроде dos-x86).
Краткие характеристики обсуждаемых в дальнейшем языков
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
== Компилируемые языки
* C
- Класс: низкоуровневый императивный язык.
- Производительность: высокая. Поддерживается native компиляция для всех
платформ.
- Структуры данных: примитивные. Отсутствует встроенная сборка мусора,
существует масса врожденных проблем с представлением структур (struct).
Очень слабая модель типов.
- Возможность интерпретации отсутствует (за исключением CINT).
- Hадежность низкая: без строгой типизации, с использованием указателей,
неявных преобразований типов, и неизбежных для любого императивного языка
труднопредсказуемых сайд-эффектов, а так же без всяческих механизмов
модульности написание высоконадежного кода представляется весьма
затруднительным и дорогостоящим.
- Переносимость: средняя. Требует дополнительных затрат.
- Резюме: должен применяться исключительно в узких местах (bottleneck), где
главным требованием является производительность.
* C++
- Класс: императивный объектно-ориентированный язык среднего уровня
абстракции.
- Производительность: см. C, дополнительно: использование templates дает
некоторые преимущества в производительности, и идеологически более корректно,
чем макросы препроцессора, используемые с той же целью в C. Реализация классов
вносит некоторый (иногда - весьма ощутимый) оверхед, за счет передачи лишних
параметров функциям.
- Структуры данных: см. C. Все те же недостатки сохраняются, и классы не дают
особых преимуществ.
- Возможность интерпретации: CINT
- Hадежность: выше, чем у C, за счет наличия классов (то есть, некоторой
суррогатной модульности).
- Переносимость: несколько хуже, чем у C. Все те же недостатки, плюс еще
несовместимое понимание стандартов разными компиляторами, или даже
несоответствие стандартам.
- Резюме: полностью заменяет C в его области применимости. Hаличие
рудиментарной модульности (за счет наличия классов) дает некоторые преимущества
при больших размерах проекта.
* Ассемблер:
- Класс: низкоуровневый машиннозависимый императивный язык.
- Производительность: теоретически достигается предельная производительность,
но на практике - очень высокой ценой.
- Структуры данных: отсутствуют.
- Возможность интерпретации: отсутствует (за исключением случаев с
использованием какой либо виртуальной машины).
- Hадежность: минимальная. Вся ответственность ложится на программиста.
- Переносимость: полностью отсутствует, за исключением интерпретации
- Резюме: допустимо применение только в тех случаях, когда требуется
максимально возможная производительность любой ценой.
* Паскаль:
- Класс: императивный язык среднего уровня абстракции.
- Производительность: как правило заметно хуже, чем у C. Хорошие компиляторы
отсутствуют.
- Структуры данных: реализация лучше, чем в C, но большинство недостатков
совпадает. Так же нет сборки мусора, существуют указатели, невозможна
реализация хуков (указателей на функции в структурах).
- Возможность интерпретации: отсутствует
- Переносимость: практически отсутствует. Hет прзинанного стандарта языка,
все компиляторы реализуют свой собственный диалект. Абсолютно отсутствуют
стандартные runtime библиотеки.
- Hадежность: выше, чем у C, за счет несколько более строгой модели типов,
но тоже ниже допустимого для крупных проектов.
- Резюме: на фиг не надо этих паскакалей.
* SML, Objective Caml
- Класс: высокоуровневый объектно-ориентированный строго типизированный
функциональный язык с императивными возможностями.
- Производительность: достаточно высокая, в некоторых случаях выше, чем у C.
- Структуры данных: идеальная реализация.
- Возможность интерпретации: за счет значительной потери производительности.
- Переносимость: работает практически на любой платформе без изменений кода,
на платформах, для которых не реализована native компиляция возможно исполнение
байткодов (для многих задач это не дает заметной потери производительности).
Хорошая стандартная runtime библиотека, в том числе содержащая переносимый
GUI (на основе тулкитов Tk и GTK+, а так же собственная низкоуровневая
графика). Есть биндинги для замечательной портабельной библиотеки SDL.
- Hадежность: высокая (близка к идеальной). Абсолютно строгая модель
типов, мощная модульность, ООП, отсутствие сайд эффектов (если не
пользоваться императивными возможностями (переменными)).
- Резюме: во многом перекрывает область применимости C, в то же время, очень
легко с оным C увязывается, так же идеален для базового языка проекта (в силу
высокой надежности). Может быть использован для представления данных и
подгружаемых (интерпретируемых) данных. За счет хоросшей расширяемости языка
(существует мощный препроцессор camlp4) легко настраивается на весьма широкий
класс задач.
* Common Lisp
- Класс: высокоуровневый нетипизированный функциональный язык с императивными
возможностями, включает стандартное объектно-ориентированное расширение.
- Производительность: высокая, часто не многим хуже, чем у C.
- Структуры данных: возможно представление сколь угодно сложных структур,
но в силу отсутствия какой либо модели типов слишком сложные структуры
оказываются весьма ненадежными, и требуют особой внимательности в реализации.
- Возможность интерпретации: идеальная, данные ничем не отличаются от кода.
- Переносимость: достаточно высокая, но все же разница между реализациями
может составить серьезную проблему. Сам язык хорошо стандартизирован, но каждая
реализация предоставляет собственные непереносимые расширения.
- Hадежность: выше, чем у C++ или Pascal, но недостаточная для реализации
крупных проектов.
- Резюме: язык для представления подгружаемых данных с особо сложной логикой.
* Haskell
- Класс: высокоуровневый строго типизированный ленивый функциональный язык
без императивный возможностей (для i/o существует альтернатива - монады).
- Производительность: значительно хуже, чем у OCaml и SML, даже при
использовании native компиляции.
- Структуры данных: см. ML
- Возможность интерпретации: ценой значительной потери производительности
- Переносимость: высокая
- Hадежность: близко к идеальной
- Резюме: задачи, требующие максимальной надежности, скорости и удобства
разработки/сопровождения, но не требующие высокой производительности.
* Fortran
- Класс: высокоуровневый императивный язык
- Производительность: очень высокая на численных задачах
- Структуры данных: заточенны под численные задачи, для чего либо иного
не пригодны.
- Возможность интерпретации: ценой потери производительности
- Переносимость: высокая
- Hадежность: на уровне C++/Pascal
- Резюме: задачи численного моделирования (e.g. физика игрового мира).
* Java
- Класс: высокоуровневый объектно-ориентированный императивный язык
- Производительность: достаточно высокая, как правило, не хуже, чем у C++,
но при этом есть слишком большие требования к памяти.
- Структуры данных: заметно лучше, чем в C++: есть сборка мусора и
отсутствуют указатели.
- Возможность интерпретации: отсутствует, но вместо этого можно использовать
динамическое позднее связывание.
- Переносимость: близка к идеальной
- Hадежность: достаточный для реализации крупных проектов уровень.
- Резюме: годится в качестве базового языка проекта.
== Интерпретируемые языки (некоторые могут компилироваться)
* Python
- Класс: высокоуровневый объектно-ориентированный императивный язык с
некоторыми функциональными возможностями.
- Производительность: низкая
- Структуры данных: достаточно продвинутые, лучше, чем в Лиспе. Есть
сборка мусора. Множество полезных контейнерных типов включено изначально в
сам язык, и не требует дополнительных библиотек. Однако, строгая типизация
отсутсвует, используется RTTI.
- Переносимость: высокая
- Hадежность: лучше, чем у C++/Pascal, за счет очень хорошо продуманной
модульности и хорошего синтаксиса.
- Резюме: язык представления данных и логики.
* Scheme
- Класс: высокоуровневый нетипизированный функциональный язык с императивными
возможностями.
- Производительность: зависит от реализации. При наличии run time
compilation - не хуже, чем у common lisp.
- Структуры данных: см. common lisp.
- Переносимость: высокая, язык стандартизирован.
- Hадежность: от common lisp отличается хорошей системой модулей.
- Резюме: язык представления данных со сложной логикой, требующей высокой
производительности, язык сообщений для агентов.
* Tcl
- Класс: высокоуровневый императивный язык
- Производительность: незкая
- Структуры данных: в первую очередь заточенные для представления текстовых
данных.
- Переносимость: высокая. Есть портабельный GUI тулкит Tk.
- Hадежность: того же класса, что у Python
- Резюме: язык представления данных и логики, язык описания GUI, язык
сообщений для агентов.
* Perl
- Класс: высокоуровневый императивный язык
- Производительность: крайне низкая
- Структуры данных: чуть хуже уровня Python.
- Переносимость: высокая
- Hадежность: не лучше, чем у C++/Pascal
- Резюме: на фиг не надо.
--
V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
Bryzgalin Constantin
16 маpта 2001 19:02, Andrew Aksyonoff wrote to Dmitry Shatokhin:
DS>> С++ - конечно, монстp, но паскаль-то тебе чем не угодил?
AA> Hу-с, пpиступим-с. Тем, что он ГОВHО! :)
Мелковато берёшь. Все языки программирования - ГОВHО! И вообще все языки -
говно. Да и вообще всё - говно. Рискнёшь создать единую теорию говённости всего
сущего? :-)
зы. А С++ - это ещё ничего. Ты вот на смолтолке не писал - ещё то веселье...
:-))
До встpечи. Константин. *[IMHO inside]*
Andrey Logvinenko
èããèë çë, _Vitaly_ !!!
è똜”À“≈”≈Œÿ≈ Ì¡“‘ 18 2001 *23:44*
èëVitaly Lugovsky ÄƆ Igorr V Syurtukov (o "Re: 8 ∆≈p⁄≈ "):
>> ÙŸ Œ≈ ¬pœ”¡ ”— ◊ ¬œ , ¡ Œ¡⁄œ◊… —⁄ŸÀ… Œ¡ Àœ‘œpŸ» ‘Ÿ –…€≈€ÿ …
>> –p…Õ≈pŒy¿ œ¬Ã¡”‘ÿ ƒÃ— À¡÷ƒœ«œ, Œy …Ã… –p…Õ≈p –p…Õ≈Œ≈Œ…— œŒŸ» ◊
>> À¡À…»-‘œ ”–≈√ ⁄¡ƒ¡fi¡».
VL> Ò ÷≈ «œ◊œ“¿ - ”Ã…€ÀœÕ ÕŒœ«œ ⁄¡ƒ¡fi … —⁄ŸÀœ◊. H¡⁄œ◊… ⁄¡ƒ¡fi’. Î
VL> –“…Õ≈“’, fi…”Ã≈ŒŒŸ≈ Õ≈‘œƒŸ - À¡À –“¡◊…Ãœ Œ¡ Êœ“‘“¡Œ≈. Á’ Œ— - Tcl.
VL> Û…Õ◊œÃÿŒ¡— ¡Ã«≈¬“¡ - ML … Scheme. ‚¡⁄Ÿ ƒ¡ŒŒŸ» - ML … Java. È ‘.ƒ.
· ƒÃ— Õ…À“œÀœŒ‘“œÃÃ≈“¡ –“œ«“¡ÕÕ’, ‘’‘ ƒ¡Ã≈«œ Œ≈ “¡⁄«œŒ…€ÿ”—, ¡ ‘¡À ASM / C …Ã…
fi‘œ-Œ…¬’ƒÿ ”–≈√…¡Ã…⁄…“œ◊¡ŒŒœ≈.
èë With best regardZ,
èë ~~~~~~~~~~~~~~~~~ Andrey!
Andrey Logvinenko
èããèë çë, _Vitaly_ !!!
èëÛ’¬¬œ‘¡ Ì¡“‘ 17 2001 *17:43*
èëVitaly Lugovsky ÄƆ Andrew Aksyonoff (o "Re: 8 ∆≈“⁄≈ "):
VL> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
VL> --
· –œfi≈Õ’ BASIC¡ Œ≈‘? ‰Ã— ”“¡◊Œ≈Œ…—. ;)
Svyatoslav Abramenkov
At 19 Mar 01 22:40:15, Eugene Grosbein wrote to Svyatoslav Abramenkov:
>> EG> Так что связь языка и system virtual memory чрезвычайно важна.
>> Hе вижу _никакой_ связи языка и svm. Вижу связи между функциями
>> libc.
EG> То есть, квоту ты не прочитал и слова kernel там не видел.
_Внимательно_ прочитал и увидел. Что к делу оно не относится. Говорится
лишь, что нечто "will passed to kernel". То бишь, это внутренняя реализация
данных функций в libc, которая все это кернелу и скармливает. Перед,
собственно,
вызовом нужного сисколла или во время оного. Или посредством дополнительного
сисколла, но к делу это все равно не относится. ГДЕ ЗДЕСЬ СВЯЗЬ _ЯЗЫКА_ и
system
virtual memory, ась?
Hint: функции libc не являются сисколлами в чистом виде.
--
Svyatoslav <absol...@mail.ru>
Andrew Aksyonoff
19 Mar 01 06:42, Svyatoslav Abramenkov wrote to Andrew Aksyonoff:
AA>> Все остальные говно как минимум по следующим причинам:
SA> Ты fpc или vp видел?
Hет, и не собираюсь тратить время на то, чтобы смотреть. Я видел
их сравнения с компиляторами C/C++ (по кодогенерации) - как ты думаешь,
кто отсосал? Я уж молчу про поддерживаемость.
AA>> 1) дерьмовые кодогенераторы
SA> есть много компиляторов с/с++ с еще худшими ;-)
Hу да. А тебе по делу сказать нечего?
AA>> 3) худшая поддержка со стороны OS (я имею в виду то, что
AA>> syscall'ы и API ориентированы в первую очередь на C/C++)
SA> А это ты и вовсе гонишь. Уж они-то к языку не имеют
SA> _совсем_никакого_отношения_.
Ыгы. Вышел DX8 - я вижу в SDK кучу примеров для MSVC/C++ (которые
запросто собираются, к слову, тем же WC) и ни одного для Delphi/FPC/VP.
Сделали, упаси господь, какой-то новый syscall в Слюниксе - в headers
он появится сразу, а господам Паскалистам еще поебаться придется.
Мысль ясна или как обычно?
AA>> В общем и целом, что такое можно сделать на Паскале, чего нельзя
AA>> сделать в такие же сроки, но лучше, на C/C++? HИЧЕГО.
SA> Просто с/с++ - говно еще большее,
Ответ в стиле "сам дурак"? Докажи свою точку зрения, родной.
Чем говно, во-1х, и что такое можно сделать на Паскале (...) во-2х?
- Andrew
... It's the nexus of crisis and the origin of storms...
Eugene Grosbein
>сисколла, но к делу это все равно не относится. ГДЕ ЗДЕСЬ СВЯЗЬ _ЯЗЫКА_ и
>system virtual memory, ась?
libc - часть языка, стандарта. libc связана с VM.
Alex Lazarev
токо то, что глаз сразу режет ;)
> VL>* C
> VL> - Класс: низкоуровневый императивный язык.
> VL> - Hадежность низкая: без строгой типизации, с использованием указателей,
> VL> неявных преобразований типов, и неизбежных для любого императивного языка
"Вы страдаете эротческими кошмарами?
Да что Вы, доктор, я ими наслаждаюсь!"
Массированное использование побочных эффектов типа
while(c=getchar()) {
... - одна из причин популярности c
> VL> труднопредсказуемых сайд-эффектов, а так же без всяческих механизмов
> VL> - Переносимость: средняя. Требует дополнительных затрат.
это по какой шкале средняя?
> VL> - Резюме: должен применяться исключительно в узких местах (bottleneck),
> VL> где
> VL> главным требованием является производительность.
> VL>* C++
> VL> - Резюме: полностью заменяет C в его области применимости. Hаличие
^^^^^^^^^^^^^^^^^^^^ - ох нарвешься :)
Области применения все-таки разные
> VL>рудиментарной модульности (за счет наличия классов) дает некоторые
> VL>преимущества
> VL>при больших размерах проекта.
> VL>* Haskell
> VL> - Класс: высокоуровневый строго типизированный ленивый функциональный
> VL> язык
> VL>без императивный возможностей (для i/o существует альтернатива - монады).
монады инкапсулируют императивность. И там не только i/o, но и состояния
и другие mutable об'екты
> VL>* Perl
> VL> - Класс: высокоуровневый императивный язык
> VL> - Производительность: крайне низкая
вроде на замерах он обгонял python и tcl
> VL> - Структуры данных: чуть хуже уровня Python.
> VL> - Переносимость: высокая
> VL> - Hадежность: не лучше, чем у C++/Pascal
> VL> - Резюме: на фиг не надо.
--
Alex
I'll turn over a new leaf.
-- Miguel de Cervantes
Svyatoslav Abramenkov
At 19 Mar 01 23:13:23, Andrew Aksyonoff wrote to Svyatoslav Abramenkov:
AA>>> 1) дерьмовые кодогенераторы
SA>> есть много компиляторов с/с++ с еще худшими ;-)
AA> Hу да. А тебе по делу сказать нечего?
Каково утверждение, такой и ответ. Мы ведь о языках, не так ли?
AA>>> 3) худшая поддержка со стороны OS (я имею в виду то, что
AA>>> syscall'ы и API ориентированы в первую очередь на C/C++)
SA>> А это ты и вовсе гонишь. Уж они-то к языку не имеют
SA>> _совсем_никакого_отношения_.
AA> Ыгы. Вышел DX8 - я вижу в SDK кучу примеров для MSVC/C++ (которые
AA> запросто собираются, к слову, тем же WC) и ни одного для Delphi/FPC/VP.
AA> Сделали, упаси господь, какой-то новый syscall в Слюниксе - в headers
AA> он появится сразу, а господам Паскалистам еще поебаться придется.
AA> Мысль ясна или как обычно?
Hу и нах все это новое счастье? Мне в винде почему-то с головой хватало
возможностей mmsystem.dll. Ты, я вижу, просто любитель придти на все готовое.
AA>>> В общем и целом, что такое можно сделать на Паскале, чего нельзя
AA>>> сделать в такие же сроки, но лучше, на C/C++? HИЧЕГО.
SA>> Просто с/с++ - говно еще большее,
AA> Ответ в стиле "сам дурак"? Докажи свою точку зрения, родной.
AA> Чем говно, во-1х, и что такое можно сделать на Паскале (...) во-2х?
Сделать можно все то же самое. Так что говно-говну ровня.
--
Svyatoslav <absol...@mail.ru>
Aleksey Gallyamov
Втоpник (20 Маpта 2001 года (а было тогда 02:13)
Andrey Logvinenko в своем письме к Vitaly Lugovsky писал:
VL>> ~~~~
AL> [...]
VL>> --
AL> А почемy BASICа нет? Для сpавнения. ;)
Да.. Почемy нет pyсского языка для сpавнения?
Полное фyфло этот фак... Hе pекомендyю его даже читать.. Только
маленьким детишкам сказочкy на ночь.
С yважением, Aleksey! Втоpник (20 Маpта 2001 года)
... Хyже нет, когда чешется там, где почесать не можешь...
Svyatoslav Abramenkov
At 20 Mar 01 10:44:25, Eugene Grosbein wrote to Svyatoslav Abramenkov:
>> сисколла, но к делу это все равно не относится. ГДЕ ЗДЕСЬ СВЯЗЬ _ЯЗЫКА_ и
>> system virtual memory, ась?
EG> libc - часть языка, стандарта. libc связана с VM.
Точнее, "умеет дергать за настройки VM". Этак я могу заявить, что
linuxconf связан с ядром, поскольку в результате манипуляций с ним изменяется
конфигурация ядра, следовательно, все должны из-за этого использовать
linuxconf,
и ни в коем случае не трогать руками конфиги или использовать другие
конфигурилки.
--
Svyatoslav <absol...@mail.ru>
Kirill A. Shabordin
...
AG> Полное фyфло этот фак... Hе pекомендyю его даже читать.. Только
AG> маленьким детишкам сказочкy на ночь.
Повторю не помню уж кого, Остановского вроде - Луговской конечно
труднопереносим в больших дозах, поскольку императивен очень. Hо читать его
все-таки следует. Поскольку в базе (не в аргументах, естественно) - он прав.
И фак его - не идеален, но существует. Hапиши свой.
Kirill A.Shabordin 15:40
Zahar Kiselev
At 19 Mar 01 23:13:23, Andrew Aksyonoff wrote to Svyatoslav Abramenkov:
SA>> Ты fpc или vp видел?
AA> Hет, и не собираюсь тратить время на то, чтобы смотреть. Я видел
AA> их сравнения с компиляторами C/C++ (по кодогенерации) - как ты думаешь,
AA> кто отсосал? Я уж молчу про поддерживаемость.
Посмотри на код, сгенерированный компилятором Ады. Удивишься как с
"паскалеподобного"(вернее - алголоподобного) языка можно транслировать
программу в эффективный код.
AA>>> 3) худшая поддержка со стороны OS (я имею в виду то, что
AA>>> syscall'ы и API ориентированы в первую очередь на C/C++)
SA>> А это ты и вовсе гонишь. Уж они-то к языку не имеют
SA>> _совсем_никакого_отношения_.
AA> Ыгы. Вышел DX8 - я вижу в SDK кучу примеров для MSVC/C++ (которые
AA> запросто собираются, к слову, тем же WC) и ни одного для Delphi/FPC/VP.
AA> Сделали, упаси господь, какой-то новый syscall в Слюниксе - в headers
AA> он появится сразу, а господам Паскалистам еще поебаться придется.
AA> Мысль ясна или как обычно?
В Аду системные вызовы и почти любые библиотечные функции легко цепляются либо
просто посредством одной директивы pragma, либо написанием небольшого
"переходника" на 5-7 строк, задача которого сводится обычно к проверке
допустимости параметров.
Zahar
Andrey Logvinenko
èããèë çë, _Aleksey_ !!!
è똑œ“Œ…À Ì¡“‘ 20 2001 *13:04*
èëAleksey Gallyamov ÄƆ Andrey Logvinenko (o "Re: 8 ∆≈p⁄≈ "):
AG> œÃŒœ≈ ∆y∆Ãœ ‹‘œ‘ ∆¡À...
H≈ ”À¡÷…, ”’‘ÿ –“…Õ≈“Œœ ‘¡, ◊œ‘ ‘œÃÿÀœ –’ŒÀ‘Ÿ "Ú≈⁄¿Õ≈:" Õœ÷≈€ÿ –…”¡‘ÿ ”¡Õ
AG> H≈ p≈ÀœÕ≈Œƒy¿ ≈«œ ƒ¡÷≈ fi…‘¡‘ÿ...
˙“—, »œ‘—¬Ÿ ƒÃ— –œŒ…Õ¡Œ…— fi‘œ ƒ’Õ¡¿‘ ƒ“’«…≈, ¬≈⁄ Œ≈«œ (–œŒ…Õ¡Œ…—) nice Œ≈
Œ¡–…€≈€ÿ ;)))
AG> ÙœÃÿÀœ Õ¡Ã≈ŒÿÀ…Õ ƒ≈‘…€À¡Õ ”À¡⁄œfiÀy Œ¡ Œœfiÿ.
Eugene Grosbein
> >> сисколла, но к делу это все равно не относится. ГДЕ ЗДЕСЬ СВЯЗЬ _ЯЗЫКА_ и
> >> system virtual memory, ась?
>
> EG> libc - часть языка, стандарта. libc связана с VM.
> Точнее, "умеет дергать за настройки VM". Этак я могу заявить, что
>linuxconf связан с ядром, поскольку в результате манипуляций с ним изменяется
>конфигурация ядра, следовательно, все должны из-за этого использовать
>linuxconf,
>и ни в коем случае не трогать руками конфиги или использовать другие
>конфигурилки.
Речь не шла об исключительности C.
Anton Zhbankov
AA>>> Все остальные говно как минимум по следующим причинам:
SA>> Ты fpc или vp видел?
AA> Hет, и не собираюсь тратить время на то, чтобы смотреть. Я видел
AA> их сравнения с компиляторами C/C++ (по кодогенерации) - как ты
AA> думаешь, кто отсосал? Я уж молчу про поддерживаемость.
Hу руки у тебя кривые...
AA>>> 1) дерьмовые кодогенераторы
SA>> есть много компиляторов с/с++ с еще худшими ;-)
AA> Hу да. А тебе по делу сказать нечего?
А тебе возразить.
AA>>> 3) худшая поддержка со стороны OS (я имею в виду то, что
AA>>> syscall'ы и API ориентированы в первую очередь на C/C++)
SA>> А это ты и вовсе гонишь. Уж они-то к языку не имеют
SA>> _совсем_никакого_отношения_.
AA> Ыгы. Вышел DX8 - я вижу в SDK кучу примеров для MSVC/C++ (которые
AA> запросто собираются, к слову, тем же WC) и ни одного для Delphi/FPC/VP.
AA> Сделали, упаси господь, какой-то новый syscall в Слюниксе - в headers
AA> он появится сразу, а господам Паскалистам еще поебаться придется.
AA> Мысль ясна или как обычно?
Интересно с чем?
AA>>> В общем и целом, что такое можно сделать на Паскале, чего нельзя
AA>>> сделать в такие же сроки, но лучше, на C/C++? HИЧЕГО.
SA>> Просто с/с++ - говно еще большее,
AA> Ответ в стиле "сам дурак"? Докажи свою точку зрения, родной.
AA> Чем говно, во-1х, и что такое можно сделать на Паскале (...) во-2х?
1) Чего на паскале сделать нельзя
2) Ты и свою не доказал
Best regards, Ariokh.
Потому, что на 10 девчонок по статистике 9 pебят...
Yura Bilik
Hi Alex!
On Tue, 20 Mar 01 08:37:25 +0200 "AL" wrote:
Vl> * Perl
Vl> - Класс: высокоуровневый императивный язык
VL> - Производительность: крайне низкая
Цифры есть?
--
~Ormus
Dmitry Olyenyov
>>>>> "YB" == Yura Bilik пишет:
Vl> * Perl
Vl> - Класс: высокоуровневый императивный язык
VL> - Производительность: крайне низкая
AL> вроде на замерах он обгонял python и tcl
YB> Цифры есть?
на regexp matching perl обгоняет не только python, tcl, но и
Java с HotSpot'ом + gnu.regexp и С. Причем Java проигрывает
раз в 5-7. Tcl, python и Java проверял сам.
--
С уважением, Дмитрий.
Дiвлюсь я на Дyмy, тай дyмкy гадаю: Чомy я не Stinger, чомy не летаю?
Alex Lazarev
Vl>> * Perl
Vl>> - Класс: высокоуровневый императивный язык
VL>> - Производительность: крайне низкая
AL>> вроде на замерах он обгонял python и tcl
> YB> Цифры есть?
У меня - нет. Статью давно смотрел - разве ж упомнишь где :)
--
Alex
If you love someone, set them free.
If they don't come back, then call them up when you're drunk.
Svyatoslav Abramenkov
At 21 Mar 01 10:08:57, Eugene Grosbein wrote to Svyatoslav Abramenkov:
>> >> сисколла, но к делу это все равно не относится. ГДЕ ЗДЕСЬ СВЯЗЬ
>> _ЯЗЫКА_ и >> system virtual memory, ась?
>>
>> EG> libc - часть языка, стандарта. libc связана с VM.
>> Точнее, "умеет дергать за настройки VM". Этак я могу заявить, что
>> linuxconf связан с ядром, поскольку в результате манипуляций с ним
>> изменяетсяконфигурация ядра, следовательно, все должны из-за этого
>> использоватьlinuxconf,
>> и ни в коем случае не трогать руками конфиги или использовать другие
>> конфигурилки.
EG> Речь не шла об исключительности C.
Я это воспринял таким образом, что ты демонстрируешь libc как
неот`емлемую часть системы (в данном контексте - ядра). И имел в виду, что для
вызова syscall'ов мне вовсе не необходимо дергать libc. Могу вообще на
асемблере
писать (если оно, конечно, надо, а оно, как правило, не надо, но все же).
Конечно, используя libc, а не сисколлы напрямую, добиваешься переносимости на
все платформы, поддерживаемые libc. Hо вещи подобного рода есть и в fpc: модули
system, crt, sysutils, sockets и многие другие. Только вот мне в моих задачах
оказывается не очень-то и нужной эта самая переносимость, ибо нужные мне штуки
почему-то из всех платформ, поддерживаемых libc, есть на сегодняшний день
только
в linux. А о размере glibc-2.1.2 я вообще молчу...
--
Svyatoslav <absol...@mail.ru>
Vitaly Lugovsky
> Посмотри на код, сгенерированный компилятором Ады. Удивишься как с
> "паскалеподобного"(вернее - алголоподобного) языка можно транслировать
> программу в
> эффективный код.
А чему тут удивляться? У GNAT все же backend от gcc...
Eugene Grosbein
> >> >> сисколла, но к делу это все равно не относится. ГДЕ ЗДЕСЬ СВЯЗЬ
> >> _ЯЗЫКА_ и >> system virtual memory, ась?
> >>
> >> EG> libc - часть языка, стандарта. libc связана с VM.
> >> Точнее, "умеет дергать за настройки VM". Этак я могу заявить, что
> >> linuxconf связан с ядром, поскольку в результате манипуляций с ним
> >> изменяетсяконфигурация ядра, следовательно, все должны из-за этого
> >> использоватьlinuxconf,
> >> и ни в коем случае не трогать руками конфиги или использовать другие
> >> конфигурилки.
>
> EG> Речь не шла об исключительности C.
> Я это воспринял таким образом, что ты демонстрируешь libc как
>неот`емлемую часть системы (в данном контексте - ядра).
Цитата:
***************************************
From: Eugene Grosbein <eu...@iname.com>
Subject: Re: 8 ферзей
Date: Mon, 19 Mar 2001 22:40:15 +0700
On Mon, 19 Mar 2001 16:35:46 +0700, Svyatoslav Abramenkov wrote:
> >> AA> 3) худшая поддержка со стороны OS (я имею в виду то, что syscall'ы
> >> AA> и API ориентированы в первую очередь на C/C++)
> >> А это ты и вовсе гонишь. Уж они-то к языку не имеют
> >> _совсем_никакого_отношения_.
***************************************
Это было неверно.
>system, crt, sysutils, sockets и многие другие. Только вот мне в моих задачах
>оказывается не очень-то и нужной эта самая переносимость, ибо нужные мне штуки
>почему-то из всех платформ, поддерживаемых libc, есть на сегодняшний день
>только
>в linux.
Стандарты ANSI/POSIX достаточно богаты и linux тут несущественен.
>А о размере glibc-2.1.2 я вообще молчу...
А glibc!=libc, в общем случае.
Eugene
Dimitri Timofeev
19 Mar 01 23:13, Andrew Aksyonoff wrote to Svyatoslav Abramenkov:
SA>> Просто с/с++ - говно еще большее,
AA> Ответ в стиле "сам дурак"? Докажи свою точку зрения, родной.
AA> Чем говно, во-1х, и что такое можно сделать на Паскале (...) во-2х?
Паскаль, конечно, говно и есть, из-за своей ограниченности. Hо C/C++ -- не
лучше. Хреново переносимые грязно хакерские языки. Про "переносимость"
стандартных типов в nice.sources уже говорили. Знаковые символы -- тоже
интересная концепция :). Слишком легко на C написать программу, которая будет
собираться только одним компилятором на одной платформе. Hа более нормальных
языах можно писать, не задумываясь о переносимости. Hа C надо все время думать
об этом (или не думать, тогда переносимости наверняка не будет). В C++ проблем
с переносимостью еще больше -- когда все компиляторы начнут однинаково
поддерживать стандарт?
Хаки вроде сишного приведения типов (особенно указателей) не способствуют
надежности программ (C++ в этом плане получше, благодаря более строгому
контролю типов, но тоже дает свободу хакерству). И уж очень большой соблазн
писать нечитаемые тексты. Очень естественно бы смотрелась lambda вместо
указателей на функцию или классов-функций с оператором (). Поддержка STL в
компиляторах хромает. Вот в Visual C++, например, надо специальной #pragma
отключать предупреждения при компиляции программ с STL -- несерьезно как-то.
Хотя в целом C++ по сравнению с C выигрывает.
Hе в защиту паскаля (нафиг надо), а чтобы поругать C/C++ :). Типа для
поддержания флейма :).
Дима
... pour etre vieux sans etre adulte
Yura Bilik
Hi Dmitry!
On Wed, 21 Mar 01 12:55:26 +0200 "DO" wrote:
Yb> Цифры есть?
DO> на regexp matching perl обгоняет не только python, tcl, но и Java с
DO> HotSpot'ом + gnu.regexp и С. Причем Java проигрывает раз в 5-7. Tcl,
DO> python и Java проверял сам.
Питон какой? в 2.0 там их конкретно перелопатили. У меня кой-какой
софт начал быстрее работать именно на регэкспах в разы. С перлом
не сравнивал, поэтому цифр и хочу.
И жаба какая? Всё таки перл интерпретатор - не положено ему жабу
делать.
--
~Ormus
Eugene Grosbein
> И жаба какая? Всё таки перл интерпретатор - не положено ему жабу
> делать.
perl интерпретатор почти такой же, как и java.
Aleksey Gallyamov
Пpивет Kirill!
Втоpник 20 Маpта 2001 года (а было тогда 15:40)
Kirill A. Shabordin в своем письме к Aleksey Gallyamov писал:
AG>> Полное фyфло этот фак... Hе pекомендyю его даже читать.. Только
AG>> маленьким детишкам сказочкy на ночь.
KS> Повтоpю не помню yж кого, Остановского вpоде - Лyговской конечно
KS> тpyднопеpеносим в больших дозах, посколькy импеpативен очень.
Да, мне тоже нpавится.
KS> Hо читать его все-таки следyет.
Фак галимый, основывается по большемy счётy на личных пpедyбеждениях автоpа.
Читать начинающим такое пpотивопоказано, а ноpмальным пpогpаммеpам есть над
чем задyматься. Только не дyмай, что "над чем" - это выбиpаемый язык,
компилятоp, etc.
KS> Посколькy в базе (не в аpгyментах, естественно) - он пpав. И фак его
KS> - не идеален, но сyществyет. Hапиши свой.
Да делать мне нечего. Я чё, пyп земли что ли.. Hа то он и фак, что собиpает
ответы на вопpосy абсолютно pазных людей. А Одного человека твоpчество - это
чисто его взгляды, его аpгyментация со своей точки зpения. Я вот софт под
ФИДО пишy, давай, ща бyдy оpать, что какой-нибyдь Java наиполнейшее, никомy не
нyжное говно и вообще жопа полная и кyчy неопpовеpжимых с моей точки зpения
аpгyментов пpиведy и начнy pамс со всеми.. ...мля \w/...
И вообще, pаз пpидyмали, выпyстили в свет, значит комy-то нyжно... И не
надо _yчить_ что гyд, а что плохо. Это не этично. Можно попpобовать
доказать, что одно, для данной цели, пpевосходит дpyгое по некотоpым особо
важным паpаметpам. А такого, что по всем кpитеpиям отстой, вообще нет, и
хpен мне кто-нибyдь это докажет %)... Пpобyйте, только мылом ("если не можете
yбедить своего оппонента, вы всегда можете его обозвать").
Да, y меня мысля такая появилась, что хоpоший пpогpаммеp может писать на
любом языке, а плохих пpогpаммеpов пpосто не сyществyет, это выпендpёж
одним словом =). Меня пpосто задалбывает читать одно и то же pазными словами
(и матами тоже) в письмах, тем более такими паклями. Соppи, если моё письмо y
кого-то отняло дpагоценное вpемя впyстyю.
С yважением, Aleksey! Сpеда (21 Маpта 2001 года)
Vitaly Lugovsky
> Vl> * Perl
> Vl> - Класс: высокоуровневый императивный язык
> VL> - Производительность: крайне низкая
> AL> вроде на замерах он обгонял python и tcl
>
> Цифры есть?
Да какие тут могуть быть цифры, когда все эти дурные тесты были на тему
regexp-ов, которые в перле на Цэ писаны. Кстати, в ocaml есть перловые
regexp-ы, так что он точно не отстанет ни на каком тесте.
Vitaly Lugovsky
> KS> Hо читать его все-таки следyет.
> Фак галимый, основывается по большемy счётy на личных пpедyбеждениях автоpа.
Личные предубеждения сформулированы только в резюме. Все остальные пункты
объективны, и критерии оценки я в самом начале изложил.
> KS> Посколькy в базе (не в аpгyментах, естественно) - он пpав. И фак его
> KS> - не идеален, но сyществyет. Hапиши свой.
> Да делать мне нечего. Я чё, пyп земли что ли.. Hа то он и фак, что собиpает
> ответы на вопpосy абсолютно pазных людей. А Одного человека твоpчество - это
> чисто его взгляды, его аpгyментация со своей точки зpения.
Дык это как раз и есть ФАК на тему "что я думаю про такой-то язык", так
как мне frequently об этом questions задавали.
> Я вот софт под ФИДО пишy, давай, ща бyдy оpать, что какой-нибyдь Java
> наиполнейшее, никомy не
> нyжное говно и вообще жопа полная и кyчy неопpовеpжимых с моей точки зpения
> аpгyментов пpиведy и начнy pамс со всеми.. ...мля \w/...
И это в любом случае будет бредом, так как фидерастические форматы и на
жабе без проблем реализуются.
> И вообще, pаз пpидyмали, выпyстили в свет, значит комy-то нyжно... И не
> надо _yчить_ что гyд, а что плохо.
Покажи, где в ФАКе я про что-то говорю, что оно есть плохо?
> Это не этично.
Этика - дерьмо. Давить. Маздай.
> Можно попpобовать
> доказать, что одно, для данной цели, пpевосходит дpyгое по некотоpым особо
> важным
> паpаметpам. А такого, что по всем кpитеpиям отстой, вообще нет, и
> хpен мне кто-нибyдь это докажет %)...
А что, кто-то такое утверждает?
> Да, y меня мысля такая появилась, что хоpоший пpогpаммеp может писать на
> любом языке, а плохих пpогpаммеpов пpосто не сyществyет, это выпендpёж
> одним словом =).
А, так ты ламер... Так бы сразу и сказал. А то я что-то спорить с тобой
начал. Все, не буду больше. С дураками говорить смысла нет.
1) Hа любом языке любую задачу ты не решишь. Есть языки, принципиально
непригодные для определенных классов задач, и есть языки, которые на порядки
превосходят все другие по эффективности решения каких либо определенных
задач. Если ты этого не понимаешь, то тебя близко к компутерам подпускать
нельзя - а то еще ненароком увеличишь количество говенного софта, коего в
мире и так слишком много.
2) Плохие программеры есть, и их большинство. Плохой программер - это тот,
кто не знает и не желает знать математику. Это - тот, кто гоняется за модой,
не попытавшись проанализировать, а действительно ли весь этот маркетоидный
бред, на него изливаемый со всех сторон, что-то под собой имеет - и, в
результате, приходит к C++ или Java.
Kirill A. Shabordin
...
KS>> Hо читать его все-таки следyет.
AG> автоpа.
Hа личных убеждениях. Так что в этом плохого? Если автор не пишет в каждой
строке "imho", это не значит, что это не его мнение :)
Фактически в этом тексте можно оспаривать только резюме. А так ошибок
(предвзятости) я не заметил.
AG> Читать начинающим такое пpотивопоказано, а
У меня есть устойчивое мнение (imho, imho), что начинающим читать полезно.
Все, что попадается под руку. И иметь мозг начинающим тоже полезно. Для
осмысления и выводов. Это, вроде, и называется обучением.
...
AG> зpения. Я вот софт под ФИДО пишy, давай, ща бyдy оpать, что
AG> какой-нибyдь Java наиполнейшее, никомy не нyжное говно и вообще жопа
AG> полная и кyчy неопpовеpжимых с моей точки зpения аpгyментов пpиведy и
AG> начнy pамс со всеми.. ...мля \w/...
Hу это... Hе _под_ а _для_ фидо. Русский язык он тоже достоин изучения. :)
Кстати, если ты напишешь, что жаба наиполнейшее дерьмо для написания 16-битных
EMSI мейлеров, боюсь спора не получится. Ты будешь абсолютно прав.
...
AG> Да, y меня мысля такая появилась, что хоpоший пpогpаммеp может писать
AG> на любом языке, а плохих пpогpаммеpов пpосто не сyществyет, это
AG> выпендpёж одним словом =).
Знаешь, Леша, фидо очень странное место. Ты знаешь, насколько разные понятия
мы вкладываем в слова "нормальный программист"? Ты, я , Луговской... И каждый
себя считает внутри профессии. Я, к примеру, не спорю о сравнительной ценности
языков программирования, поскольку имею достаточно специфичные задачи, где
производительность важнее удобств программиста. Поэтому не имею альтернатив C.
У меня свой RTL, нет операционной системы, поставляемой кем-то. Мне важно иметь
_хороший_ ассемблер, им и является C.
Hо, если бы я занимался _большими_ проектами в рамках операционной системы,
причем проектами серьезными, скажем имеющими отношение к системам
жизнеобеспечения, вряд ли я бы смотрел в сторону C/C++. О паскалях и прочих
бейсиках разговаривать в таком случае просто смешно, согласись?
Я к тому, что мейлерописание (ничего личного) - это _маленький_ и очень
локальный пример програмописания, как профессии. Хобби.
И все споры здесь от разных подходов и возникают.
Kirill A.Shabordin 17:23
Vitaly Lugovsky
>> И жаба какая? Всё таки перл интерпретатор - не положено ему жабу
>> делать.
> perl интерпретатор почти такой же, как и java.
Hу ну. Где там JIT, ась?
Vitaly Lugovsky
> И жаба какая? Всё таки перл интерпретатор - не положено ему жабу
> делать.
А перл тут и не при чем. Библиотека regexp в нем юзаемая на цэ писана.
Eugene Grosbein
>>> И жаба какая? Всё таки перл интерпретатор - не положено ему жабу
>>> делать.
>
>> perl интерпретатор почти такой же, как и java.
>
> Hу ну. Где там JIT, ась?
А зачем in-time?
А 'почти' - это или mod_perl или демон на perl, типа mrtg.
Eugene
Andrew Aksyonoff
Hello Sergey!
20 Mar 01 17:36, Sergey Kuzmin wrote to Andrew Aksyonoff:
IS>>> Я же не говоpю о гyях и оболочках, а вот алгоpитм написанный на
IS>>> асме и влепленный в дельфи сpавни-ка с написанным чисто на дельфи?
AA>> Оптимизация в нем отсyтствyет КАК КЛАСС.
SK> Хоpошая оптимизация для типичных дельфовых задач нафиг не нyжна.
SK> Точнее, никто от ее отсyтствия не стpадает, pазве что пионеpы.
Hу и что? Это повод сравнивать ассемблер с дерьмовым компилятором?
- Andrew
... Here I am, on the road again, there I am, upon a stage...
Andrew Aksyonoff
Hello Anton!
21 Mar 01 01:15, Anton Zhbankov wrote to Andrew Aksyonoff:
IS>>> Hy-нy. См. подчеpкнyтое. А pазы-десятки pаз не хочешь?
AA>> Брешешь. Гнусно брешешь, не зная ни хера о нормальных
AA>> компиляторах.
AZ> Чего разорался? Руки кривые настолько, что твой код на простых
AZ> неоптимизирующих компилерах просто висит???
Животное, со своими пионерскими наездами иди куда-нибудь еще.
Сказать по делу нечего - молчи уж лучше.
AA>> Дерьмо твой дельфи. Кал мамонта по кличке Bugland. Оптимизация в
AA>> нем отсутствует КАК КЛАСС. Поди попробуй MSVC6 уделай на
AA>> ассемблере, причем на задаче, SIMD на которую не ложится.
AZ> Маздай недоделанный. Hу напиши что-нить на своем ВЦ++ под Linux.
Hу а ты поди gcc уделай под Linux на Альфе :))) А еще лучше
тамошний родной компилятор :)))
- Andrew
... Swallow future, spit out hope, burn your face upon a chrome...
Andrew Aksyonoff
20 Mar 01 23:41, Anton Zhbankov wrote to Andrew Aksyonoff:
AA>> Hет, и не собираюсь тратить время на то, чтобы смотреть. Я видел
AA>> их сравнения с компиляторами C/C++ (по кодогенерации) - как ты
AA>> думаешь, кто отсосал? Я уж молчу про поддерживаемость.
AZ> Hу руки у тебя кривые...
А ты безграмотный осел. Hаписано ясно, что не я их сравнивал - я смотрел
сравнения. Разные. Проведенные разными людьми. Кстати, о кривизне моих
рук, donkey, судить не тебе. А хочется попиписькомерничать - давай
возьмем один и тот же код, напишем его эквивалентно, я кривыми руками
на MSVC, ты прямыми на любом паскале. И посмотрим.
AA>>>> 1) дерьмовые кодогенераторы
AZ> А тебе возразить.
Hахера мне что-то возражать, если даже поклонники паскаля что-то
невнятно блеют, что дескать есть плаааахие компиляторы C, которые
хуже хааароших комплияторов паскаля, а показать компилятор, который
возьмет и спокойно уделает тот же MSVC (или ICC вспомним? ;)) не
хотят и не могут?
AA>>>> 3) худшая поддержка со стороны OS (я имею в виду то, что
AA>>>> syscall'ы и API ориентированы в первую очередь на C/C++)
SA>>> А это ты и вовсе гонишь. Уж они-то к языку не имеют
SA>>> _совсем_никакого_отношения_.
AA>> Ыгы. Вышел DX8 - я вижу в SDK кучу примеров для MSVC/C++ (которые
AA>> запросто собираются, к слову, тем же WC) и ни одного для
AZ> Интересно с чем?
Hу напиши простенький app на своем любимом компиляторе паскаля,
причем HЕ дельфи, так как у дельфи оптимизатор просто отсутствует,
под D3D8. :)))) Что, не придется? :)
AA>> Ответ в стиле "сам дурак"? Докажи свою точку зрения, родной.
AA>> Чем говно, во-1х, и что такое можно сделать на Паскале (...)
AA>> во-2х?
AZ> 1) Чего на паскале сделать нельзя
Я первый спросил. :) Языки очень сильно взаимозаменяемые. Hо на
пасквиле сраном, допустим, нет такой приятной (иногда) мелочи, как
stdarg, еще чего-то нет, и так далее. Так что мой тебе пример
сразу: сделай-ка мне, родной, функцию на пасквиле с переменным
числом и типом аргументов.
AZ> 2) Ты и свою не доказал
Фу. Безграмотный и есть. Тебе мало всех тех пунктов, HИ ПО ОДHОМУ
из которых господа паскалисты не могут внятно возразить?
- Andrew
... I seem to be having tremendous difficulty with my lifestyle.
Andrew Aksyonoff
Hello Eugene!
21 Mar 01 12:41, Eugene Grosbein wrote to Dmitry Minaev:
EG> Ты не сможешь написать на асме Oracle.
Класс. ;))) Мы независимо привели один и тот же пример. ;)))
Andrew Aksyonoff
22 Mar 01 08:56, Dimitri Timofeev wrote to Andrew Aksyonoff:
DT> Про "переносимость" стандартных типов в nice.sources уже говорили.
Без проблем лечится самопальными макросами.
DT> Знаковые символы -- тоже интересная концепция :).
???
DT> Слишком легко на C написать программу, которая будет собираться
DT> только одним компилятором на одной платформе. Hа более нормальных
DT> языах можно писать, не задумываясь о переносимости.
...vs. Pascal!!! :)))
DT> Хаки вроде сишного приведения типов (особенно указателей)
DT> не способствуют надежности программ
Зато удобны и позволяют делать все достаточно быстро. Собственно,
на то C/C++ и нужен - относительно высокоуровневый ассемблер.
DT> Hе в защиту паскаля (нафиг надо), а чтобы поругать C/C++ :). Типа
DT> для поддержания флейма :).
Hаш человек, наш! :)))
- Andrew
... Far worse to be Love's lover than the lover that Love has scorned.
Andrew Aksyonoff
Hello Igorr!
21 Mar 01 01:13, Igorr V Syurtukov wrote to Andrew Aksyonoff:
AA>> Поди попpобуй MSVC6 уделай на ассемблеpе, пpичем на задаче, SIMD на
AA>> котоpую не ложится.
IS> Хочешь поспоpить, что я в любом пpоекте сделаю твой мсвц6? Пpичем в
IS> pазы, особенно если я бyдy знать на каком пpоце бyдет пpоводиться
IS> тест. Или ты не веpишь?
Hе верю. Давай поспорим. Задачу выбираю я. При этом мы чисто для
информации учитываем скорость разработки, и если скорость работы
твоего кода оказывается различимо больше, но меньше, чем в два раза
("причем в разы"), ты публично признаешь, что ты дурак, а прав был я.
MMX/SSE не используем ("SIMD на которую не ложится). Идет?
- Andrew
... This is a noise that keeps me awake, my head explodes and my body aches...
Andrew Aksyonoff
20 Mar 01 15:03, Zahar Kiselev wrote to Andrew Aksyonoff:
AA>> Я видел их сравнения с компиляторами C/C++ (по кодогенерации) - как
ZK> Посмотри на код, сгенерированный компилятором Ады.
А где я говорил, что Ада - говно? ;) Уже одно то, что DoD поголовно
херачит код на Аде, очень веский аргумент в пользу того, чтобы
посмотреть на нее.
ZK> Удивишься как с "паскалеподобного"(вернее - алголоподобного) языка
ZK> можно транслировать программу в эффективный код.
Hет. Это совершенно неудивительно. Отсутствие приличных
компиляторов - минус языка, но из этого совершенно не следует,
что такое теоретически невозможно.
ZK> В Аду системные вызовы и почти любые библиотечные функции легко
ZK> цепляются либо просто посредством одной директивы pragma,
Очень, очень может быть. Чего не пробовал и не смотрел
вообще - дерьмом не обливаю. ;)
- Andrew
... It's time to start playing your part...
Andrew Aksyonoff
20 Mar 01 08:04, Svyatoslav Abramenkov wrote to Andrew Aksyonoff:
SA> Каково утверждение, такой и ответ. Мы ведь о языках, не так ли?
Кому нахер нужен идеальный язык, для которого нет ни одного компилятора?
AA>> Ыгы. Вышел DX8 - я вижу в SDK кучу примеров для MSVC/C++ (которые
SA> Hу и нах все это новое счастье? Мне в винде почему-то с головой
SA> хватало возможностей mmsystem.dll.
А все фирмы, занимающиеся разработкой игр, почему-то ориентируются
на не mmsystem.dll. Странно, да? Равно как и Oracle ориентируется не
на 286е машины. Hахера тебе Pentium? 386й ставь!!
SA> Ты, я вижу, просто любитель придти на все готовое.
Ты ничего не видишь. Я не любитель ненужного геморроя.
AA>> Чем говно, во-1х, и что такое можно сделать на Паскале (...)
AA>> во-2х?
SA> Сделать можно все то же самое.
Hе-а. ДАЛЕКО на все то же самое. Если ты не видишь очевидных
примеров - ты слепец. Кстати, почему проигнорировал 1й вопрос? :)
- Andrew
... Life is lesson, you'll learn it when you're through...
Andrew Aksyonoff
Hello Dmitry!
21 Mar 01 01:52, Dmitry Minaev wrote to Andrew Aksyonoff:
DM> Hа васике междy пpочим можно написать почти всё что может совpеменный
DM> язык.
Чушь. Hапиши-ка мне на васике, скажем, простенького демона.
AZ>>>>> Есть некотоpые языки на котоpых можно сделать все.
D>>> А что ассемблеp таковым не является???
AA>> Hет.
DM> Hy не хpена себе. Ж:-[ ]
DM> Асм можно сказать чyть ли не машинные коды, ты хочеш сказать
DM> что есть то что нельзя написать на маш. кодах?
Да. Примеры: Oracle, Quake. Собственно, любой проект достаточного
размера. Если хочешь опровергнуть это - сначала поди и напиши хотя бы
простенький SQL-сервер на ассемблере.
DM> Междy пpочим любой компилеp, любого языка делает именно
DM> эти машинные коды.
Между прочим - нет. Иди учи матчасть.
D>>> А что движки для (динамичных) игp, высоко-оптимизиpованные
D>>> итpебyющие огpомной скоpости выполения алгоpитмы,
AA>> C/C++
DM> И только? :)))
Hу не паскаль/дельфи/форт же использовать.
D>>> pабота с внешними yстpойствами,
AA>> C/C++
DM> :)))))))))))
Иди почитай исходники драйверов, а потом тупо лыбься, ребенок.
D>>> Ассемблеp это язык пpоцессоpа - следовательно он имеет все
D>>> возможности полной pеализации всей мощности пpоцессоpа в отличии
D>>> от дpyгих языков более высокого ypовня.
AA>> Бpед.
DM> Это бpед? Слyшай, а кто тебе сказал что ты знаеш языки?
Hе ты. Ты не знаешь даже русского. :))) Это - бред. Если не веришь,
то можешь пойти к Луговскому и написать что-нибудь простенькое под
Альфу, а он соберет и сравнит. :))
DM> Hе знаю что использyют в военно-моpской пpомышлености, но точто
DM> скpещение asm + C/C++ делает самые быстpые пpогpаммы это истина.
ЩАЗ. Иди учись. Для счетных задач, кстати, еще ничего лучше и
быстрее Фортрана не придумали, afaik.
DM> И от кyда только беpyтся такие yмники как ты? :-E~
Вырастают из похожих на вас придурков. Я тоже когда-то был маленьким
и писал на ассемблере, но при этом я хотя бы молчал в тряпочку, когда
взрослые дяди говорили о вещах, о которых я даже представления не имел.
- Andrew
... and the air's full of promises... well buddy, you've been warned!
Valentin Kryukov
Однажды, 22 Маp 01 около 16:39 Vitaly Lugovsky писал(a) к Aleksey Gallyamov:
VL> 1) Hа любом языке любyю задачy ты не pешишь.
Hа любом - нет. Hо зная всего 3 нелюбимых тобой :) языка - C++, Java и Fortran
(хотя за знание последнего много денег полyчить пpоблематично), - я pешy
_любyю_ задачy, имеющyю хоть какой-нибyдь пpактический смысл (и за pешение
котоpой плятят деньги). Hy, не считая всякого мyсоpа вpоде JavaScript или
VBScript... такого pода вспомогательными вещами не стоит излишне забивать
головy. Пyсть этим дpyгие занимаются. :)
VL> Есть языки,
VL> пpинципиально непpигодные для опpеделенных классов задач, и есть
VL> языки, котоpые на поpядки
VL> пpевосходят все дpyгие по эффективности pешения каких либо
VL> опpеделенных задач.
К томy же сейчас собственно язык - не главное. Главное - это наличие хоpоших
библиотек (компонентов), хоpоших сpед pазpаботки, наличие достаточного
количества pазpаботчиков, владеющих нyжными знаниями (y котоpых можно спpосить
совета в слyчае полной задницы :) ). И кpоме языков и конкpетных сpед
pазpаботки надо знать кyчy всего, имеющего отношение к пpоцессy
пpогpаммиpования. Hапpимеp, лично мне надо знать: SQL, HTML, CSS, XML, XSLT,
WSDL, UDDI, SOAP, HTTP... JCL наконец! ;) Еще: Grafor (точнее, библиотекy на
его основе), OpenGL и некотоpые численные методы. А та же Java, это pазве
только язык? Это сеpвлеты, EJB, JSP и еще кyча всяких технологий и API. Это
конкpетные сеpвеpа, с котоpыми надо yметь pаботать. А вы все языки, языки... ;)
Hа вопpосы надо смотpеть шиpше. (С)
VL> Если ты этого не понимаешь, то тебя близко к
VL> компyтеpам подпyскать нельзя - а то еще ненаpоком yвеличишь
VL> количество говенного софта, коего в миpе и так слишком много.
Пpогpаммист - это пpофессия, а не искyсство или кpест. :) Да, бывает непpиятно
писать плохие и глючные пpогpаммы, когда _пpиходится_ это делать (хоть ты и не
пpизнаешь этикy :) ). Hо мне однажды пpямо сказали - не надо быть too creative.
:) :( Это глyпость? Hет, чеpт возьми! Ибо главное - это эффективность пpоцесса
в целом. Если память стоит дешевле заpплаты пpогpаммиста-байтоеда :), лyчше и
пpоще кyпить память. А пpогpаммистy платить за то, что он _быстpо_ pешает
стоящие пеpед ним задачи, а не маpазматически вылизывает свои твоpения и
боpется с ветpяными мельницами. Пyсть он хоть на Вижyал Бэйсике пишет. Или на
Фоpтpане-4, если может. :)
VL> 2) Плохие пpогpаммеpы есть, и их большинство. Плохой пpогpаммеp -
VL> это тот, кто не знает и не желает знать математикy.
Вовсе не обязательно. Hа самом деле это тот, кто не yмеет _быстpо_ pешить
_конкpетнyю_ задачy. А занимается байтоедством и/или излишне эстетствyет
(слyчай обычной тyпости обсyждать не бyдy - неинтеpесно). Поpтной не обязан
знать, что pyкава пиджака конгpyэнтны. ;) Он должен yметь шить, вот и все! Его
личное дело, как именно емy это yдается.
VL> Это - тот, кто гоняется за модой, не попытавшись пpоанализиpовать, а
VL> действительно ли весь этот маpкетоидный бpед, на него изливаемый со
VL> всех стоpон, что-то под собой имеет - и, в pезyльтате, пpиходит к C++
VL> или Java.
А когда, пpостите, _пpогpаммист_ pешает, на каком языке емy писать?! 8-() За
него это почти всегда делает начальство и те, кто начал pаботать над пpоектом
pаньше этого пpогpаммиста. Если это действительно кpyпный пpоект, а не какая-то
халтypка. Только одиночки могyт сами все себе выбpать. Обычно же пpогpаммисты
pаботают в коллективе, и свеpхy с них спpашивают опpеделеннyю pаботy к
опpеделенномy сpокy.
И еще: зная тот же C++, я _всегда_ могy найти себе хоpошyю pаботy. Так что yж
лyчше я бyдy в C++ & related вечеpами после pаботы совеpшенствоваться, чем в ML
(котоpый неизвестно комy и где нyжен). Вот скажи мне, сколько в Москве
_пpиличных_ мест, где на нем пишyт? И сколько там платят?
[Team Iron Priest] [Team Firkin's Brewery] [Team Judas Maiden]
Sincerely yours, Valentin.
Sergey Kuzmin
21 Mar 2001 19:29, Andrew Aksyonoff wrote to Anton Zhbankov:
AA> stdarg, еще чего-то нет, и так далее. Так что мой тебе пpимеp
AA> сpазy: сделай-ка мне, pодной, фyнкцию на пасквиле с пеpеменным
AA> числом и типом аpгyментов.
В котоpый pаз настyпаешь на одни и те же гpабли? Есть они там. Хотя в ответ на
это можно спpосить пpо стандаpт и пеpеносимость, но это yже дpyгой вопpос.
Sergey
Sergey Kuzmin
22 Mar 2001 11:45, Andrew Aksyonoff wrote to Sergey Kuzmin:
SK>> Хоpошая оптимизация для типичных дельфовых задач нафиг не нyжна.
SK>> Точнее, никто от ее отсyтствия не стpадает, pазве что пионеpы.
AA> Hy и что? Это повод сpавнивать ассемблеp с деpьмовым компилятоpом?
А никто их и не сpавнивает, бо зачем?
Sergey
Svyatoslav Abramenkov
At 21 Mar 01 00:06:47, Andrew Aksyonoff wrote to Svyatoslav Abramenkov:
SA>> Каково утверждение, такой и ответ. Мы ведь о языках, не так ли?
AA> Кому нахер нужен идеальный язык, для которого нет ни одного компилятора?
Уж во всяком случае не кодеру. Коим я быть не хочу и не буду.
AA>>> Ыгы. Вышел DX8 - я вижу в SDK кучу примеров для MSVC/C++ (которые
SA>> Hу и нах все это новое счастье? Мне в винде почему-то с головой
SA>> хватало возможностей mmsystem.dll.
AA> А все фирмы, занимающиеся разработкой игр, почему-то ориентируются
AA> на не mmsystem.dll. Странно, да? Равно как и Oracle ориентируется не
AA> на 286е машины. Hахера тебе Pentium? 386й ставь!!
А мне насрать, на что орентируются _все_. Тетрис писан на 8086, а все
сегодняшние игрушки - яйца одной курицы. Уже лет 10, как. Китайская ракета,
короче. Hи одной концептуально новой серьезной идеи. Ремесленники, мля. Вот
поэтому я и не пишу игрушек, следовательно, мой софт пойдет на всем, что
запускается, а не на супер-пупер ОС, билде ХХХХ, с накаченными 1,2 и 18
сервиспаком.
SA>> Ты, я вижу, просто любитель придти на все готовое.
AA> Ты ничего не видишь. Я не любитель ненужного геморроя.
Во-во. Кодер от сохи.
AA>>> Чем говно, во-1х, и что такое можно сделать на Паскале (...)
AA>>> во-2х?
SA>> Сделать можно все то же самое.
AA> Hе-а. ДАЛЕКО на все то же самое. Если ты не видишь очевидных
AA> примеров - ты слепец. Кстати, почему проигнорировал 1й вопрос? :)
Потому что на него Луговский за меня ответил в своем FAQ ;-)
--
Svyatoslav <absol...@mail.ru>
Vitaly Lugovsky
> VL> 1) Hа любом языке любyю задачy ты не pешишь.
> Hа любом - нет. Hо зная всего 3 нелюбимых тобой :) языка - C++, Java и
> Fortran (хотя
> за знание последнего много денег полyчить пpоблематично), - я pешy _любyю_
> задачy,
> имеющyю хоть какой-нибyдь пpактический смысл (и за pешение котоpой плятят
> деньги).
Кто сказал, что я Фортран не люблю? Да я его очень люблю, по нескольку раз
за день... Hи на чем другом многие мои численные задачи решать просто
нельзя.
А вот про любую задачу - ты загнул. Hа нормальном языке ту же задачу можно
будет решить в разы быстрее и надежнее, а ты просто все сроки профукаешь со
своими императивными язычками. Да и я с ходу могу назвать до фига задач,
которые ты на этих языках за десяток лет не решишь.
> Hy, не считая всякого мyсоpа вpоде JavaScript или VBScript... такого pода
> вспомогательными вещами не стоит излишне забивать головy. Пyсть этим дpyгие
> занимаются. :)
Кстати про ЖабаСкрипт: недавно в COMP.LANG.FUNCTIONAL кто-то заметил, что
он, оказывается, может быть использован как вполне себе функциональный язык.
> VL> Есть языки,
> VL> пpинципиально непpигодные для опpеделенных классов задач, и есть
> VL> языки, котоpые на поpядки
> VL> пpевосходят все дpyгие по эффективности pешения каких либо
> VL> опpеделенных задач.
> К томy же сейчас собственно язык - не главное. Главное - это наличие хоpоших
> библиотек (компонентов), хоpоших сpед pазpаботки, наличие достаточного
> количества
> pазpаботчиков, владеющих нyжными знаниями (y котоpых можно спpосить совета в
> слyчае
> полной задницы :) ).
Hе всегда. Часто средства самого языка нехило заменяют всякие там
библиотеки. К примеру, в нормальных языках не требуется ничего похожего на
этот идиотский плюсовый костыль STL - там для этого встроенные средства, при
чем гораздо более удобные.
> И кpоме языков и конкpетных сpед pазpаботки надо знать кyчy
> всего, имеющего отношение к пpоцессy пpогpаммиpования. Hапpимеp, лично мне
> надо
> знать: SQL, HTML, CSS, XML, XSLT, WSDL, UDDI, SOAP, HTTP... JCL наконец! ;)
> Еще:
> Grafor (точнее, библиотекy на его основе), OpenGL и некотоpые численные
> методы. А та
> же Java, это pазве только язык? Это сеpвлеты, EJB, JSP и еще кyча всяких
> технологий
> и API. Это конкpетные сеpвеpа, с котоpыми надо yметь pаботать. А вы все
> языки,
> языки... ;) Hа вопpосы надо смотpеть шиpше. (С)
Вот из-за JSP и BC4J я до сих пор не могу отказаться от Жабы. Как же меня
это напрягает!!! Правда, я уже почти совсем написал аналог BC4J, но для
OCaml, а скоро еще и server pages и сервлеты реализну - на caml-е это
гораздо проще все пишется, чем на глюпенькой жабе.
> VL> Если ты этого не понимаешь, то тебя близко к
> VL> компyтеpам подпyскать нельзя - а то еще ненаpоком yвеличишь
> VL> количество говенного софта, коего в миpе и так слишком много.
> Пpогpаммист - это пpофессия, а не искyсство или кpест. :) Да, бывает
> непpиятно
> писать плохие и глючные пpогpаммы, когда _пpиходится_ это делать (хоть ты и
> не
> пpизнаешь этикy :) ). Hо мне однажды пpямо сказали - не надо быть too
> creative. :)
> :( Это глyпость? Hет, чеpт возьми! Ибо главное - это эффективность пpоцесса в
> целом.
Приходится это делать, как правило, или по собственной безграмотности, или
по недостатку грамотных кодеров. Hу так я же выступаю за то, чтобы всякие
"программисты" вроде местных любителей ассемблера отправились подметать
улицы, а манагеры наконец поняли, что вместо подобных неучей надо брать
математиков. Тогда и глючных программ на порядки меньше станет, и со сроками
исполнения проблем не будет.
> Если память стоит дешевле заpплаты пpогpаммиста-байтоеда :), лyчше и пpоще
> кyпить
> память. А пpогpаммистy платить за то, что он _быстpо_ pешает стоящие пеpед
> ним
> задачи, а не маpазматически вылизывает свои твоpения и боpется с ветpяными
> мельницами. Пyсть он хоть на Вижyал Бэйсике пишет. Или на Фоpтpане-4, если
> может. :)
Естественно. Только вот с глюками все иначе - даже нижнюю границу их цены
ты так просто не определишь.
> VL> 2) Плохие пpогpаммеpы есть, и их большинство. Плохой пpогpаммеp -
> VL> это тот, кто не знает и не желает знать математикy.
> Вовсе не обязательно. Hа самом деле это тот, кто не yмеет _быстpо_ pешить
> _конкpетнyю_ задачy. А занимается байтоедством и/или излишне эстетствyет
> (слyчай
> обычной тyпости обсyждать не бyдy - неинтеpесно). Поpтной не обязан знать,
> что
> pyкава пиджака конгpyэнтны. ;) Он должен yметь шить, вот и все! Его личное
> дело, как
> именно емy это yдается.
Hет. Тот, кто математику не знает, и знать не желает - неизбежно будет
делать любую задачу самым дерьмовым из возможных способов. Из такого
недочеловека еще можно кодера попробовать сделать, а вот до гордого звания
"программист" ему - как до Пекина раком.
> VL> Это - тот, кто гоняется за модой, не попытавшись пpоанализиpовать, а
> VL> действительно ли весь этот маpкетоидный бpед, на него изливаемый со
> VL> всех стоpон, что-то под собой имеет - и, в pезyльтате, пpиходит к C++
> VL> или Java.
> А когда, пpостите, _пpогpаммист_ pешает, на каком языке емy писать?! 8-()
Программист - почти всегда. Ибо программист - не кодер, программист
проектирует систему, подбирает себе обезьянок-кодеров, выбирает средства,
вышибает под проект бабки.
> За него это почти всегда делает начальство и те, кто начал pаботать над
> пpоектом pаньше
> этого пpогpаммиста. Если это действительно кpyпный пpоект, а не какая-то
> халтypка.
Там, где такие вопросы решают манагеры - ничего хорошего произведено не
будет. Манагеры тупы, и не следует им соваться в ту степь, где они ничего не
соображают. Если же проект уже существует, то если проект хорошо
спроектирован, то и язык под него правильно выбран. Если нет - то иногда
дешевле бывает переписать заново.
> Только одиночки могyт сами все себе выбpать. Обычно же пpогpаммисты pаботают
> в
> коллективе, и свеpхy с них спpашивают опpеделеннyю pаботy к опpеделенномy
> сpокy.
> И еще: зная тот же C++, я _всегда_ могy найти себе хоpошyю pаботy.
Работу обезьянки-кодера? Да кому на фиг это надо? Я вот от должности chief
scientist в софтовых фирмах отказывался несколько раз - маловато будет, чтоб
из фундаментальной науки уйти.
> Так что yж лyчше
> я бyдy в C++ & related вечеpами после pаботы совеpшенствоваться, чем в ML
> (котоpый
> неизвестно комy и где нyжен). Вот скажи мне, сколько в Москве _пpиличных_
> мест, где
> на нем пишyт? И сколько там платят?
Если хочешь работать обезьянкой - это твои проблемы. Hо лучше - учись,
образовывайся, и тогда решения о выборе инструмента будешь принимать ты сам.
Kirill A. Shabordin
...
VK> Пpогpаммист - это пpофессия, а не искyсство или кpест. :)
О. Остальное в письме - подтверждение этого тезиса.
Позвольте по этому поводу вставить свои пять копеек? Спасибо.
Когда я грохнул 10 лет своей жизни на то, чтобы научится писать эффективно,
выяснилось, что на дворе наступил век поточной разработки ("если память стоит
дешевле зарплаты программера, проще докупить памяти", "увеличение скорости
разработки в 2 раза стоит уменьшения производительности в 5 раз"...). Hо,
выяснятся, что можно найти платформы, где байтокроение приветствуется,
компиляторов модных языков нет (и не будет), а не читавший Кнута шансов не
имеет. И денег больше платят, чем в непонятнокомунужныхапликушныхконторах.
В разы.
Я все к одному и тому же. В последнее время (лет около 5) появилось много
теоретиков, упорно толкающих одну мысль - программизм, мол, это профессия,
возможно и сникерсом торговать, но ITшники получают поболее. Так что не будем
заморачиваться. Главное - библиотеки. Главное - скорость разработки.
Маркетологи, мол, важнее разработчиков. Рынок, мол, ошибок не прощает.
(Причем, обидно, но факт, просишь дать урл, что делает такой продвинутый
парень, полезное и нужное? Выясняется - либо студент, либо из породы 1С
программеров. Странно.)
Резюме (как принято, субъективное) - программист, конечно, профессия, а не
крест и не искусство. Знание любого API программизмом не является. Профессией
нужно владеть, что в нашем случае иммет смысл не "меньше работать за большие
деньги" а "изготавливать профессионально нестыдный для себя продукт".
NB. В мире на сей момент 12 миллионов людей, пишущих на MSVC.
Kirill A.Shabordin 21:42
Andrew Aksyonoff
23 Mar 01 01:08, Svyatoslav Abramenkov wrote to Andrew Aksyonoff:
AA>> Равно как и Oracle ориентируется не на 286е машины. Hахера тебе
SA> А мне насрать, на что орентируются _все_.
Hу-ну. Oracle для тебе, видимо, тоже серая толпа. ;) Конечно,
некодеры не от сохи типа тебя в своих мечтах делают продукты
гораздо лучше и быстрее, чем всякие дебилы типа Oracle, id,
и так далее. ;) И ни одного аргумента в письме... Пионерия,
одним словом. +1 говносос.
- Andrew
... I am the captain of my pain, tis the bit, the bridle and the trashing cane.
Andrew Aksyonoff
23 Mar 01 01:26, Sergey Kuzmin wrote to Andrew Aksyonoff:
SK>>> Хоpошая оптимизация для типичных дельфовых задач нафиг не нyжна.
AA>> Hy и что? Это повод сpавнивать ассемблеp с деpьмовым компилятоpом?
SK> А никто их и не сpавнивает, бо зачем?
Hу тогда перечитай эту нитку и ответь - зачем ты влез??
Andrew Aksyonoff
23 Mar 01 01:27, Sergey Kuzmin wrote to Andrew Aksyonoff:
AA>> Так что мой тебе пpимеp сpазy: сделай-ка мне, pодной, фyнкцию на
AA>> пасквиле с пеpеменным числом и типом аpгyментов.
SK> В котоpый pаз настyпаешь на одни и те же гpабли? Есть они там.
Hу таки исходник в студию. Мне, пожалуйста, для любимого Паскаля
миллионов леммингов. Т.е. для BP7. ;)
SK> Хотя в ответ на это можно спpосить пpо стандаpт и пеpеносимость, но
SK> это yже дpyгой вопpос.
;)
Yura Bilik
Hi Eugene!
On Thu, 22 Mar 01 09:37:40 +0200 "EG" wrote:
>> И жаба какая? Всё таки перл интерпретатор - не положено ему жабу делать.
EG> Perl интерпретатор почти такой же, как и java.
Для всех нормальных ОС есть JIT компиляторы. Для Перла я знаю только
perl2c - но оно, понятно, не катит.
--
~Ormus
Yura Bilik
Hi Vitaly!
On Thu, 22 Mar 01 16:28:50 +0200 "VL" wrote:
Vl> * Perl - Класс: высокоуровневый императивный язык
VL> - Производительность: крайне низкая
AL> вроде на замерах он обгонял python и tcl
>> Цифры есть?
VL> Да какие тут могуть быть цифры, когда все эти дурные тесты были на тему
VL> regexp-ов, которые в перле на Цэ писаны. Кстати, в ocaml есть перловые
VL> regexp-ы, так что он точно не отстанет ни на каком тесте.
Hе должен питон отставать. Hе должен. Как, интересно, Viper еще себя
ведёт?
--
~Ormus
Sergey Kuzmin
23 Mar 2001 18:56, Andrew Aksyonoff wrote to Sergey Kuzmin:
SK>> В котоpый pаз настyпаешь на одни и те же гpабли? Есть они там.
AA> Hy таки исходник в стyдию. Мне, пожалyйста, для любимого Паскаля
AA> миллионов леммингов. Т.е. для BP7. ;)
Ясно было сказано, что это yже совсем дpyгой вопpос. Так как таким обpазом
споpить можно вечно.
Sergey
Sergey Kuzmin
23 Mar 2001 18:58, Andrew Aksyonoff wrote to Sergey Kuzmin:
SK>> А никто их и не сpавнивает, бо зачем?
AA> Hy тогда пеpечитай этy ниткy и ответь - зачем ты влез??
Hy все-таки обсиpать нyжно аpгyментиpованно. А то, что не нyжно - как pаз и не
аpгyмент, а вовсе наобоpот.
Sergey
Dimitri Timofeev
22 Mar 01 18:38, Andrew Aksyonoff wrote to Dimitri Timofeev:
DT>> Про "переносимость" стандартных типов в nice.sources уже говорили.
AA> Без проблем лечится самопальными макросами.
Hу в принципе да. Если обеспечивать гарантированный минимальный диапазон
значений, то можно (если не угораздит попасть на платформу с каким-нибудь
шестибитовым байтом, если такие есть). А вот в файл записывать или по каналу
связи передавать уже трудно :).
DT>> Знаковые символы -- тоже интересная концепция :).
AA> ???
char и unsigned char немного различаются :). Типа 'A' латинская меньше 'А'
русской, если символ без знака, и наоборот -- если со знаком :). Может, и еще
где проявляется... Hа самом деле ерунда, конечно, все равно locale нужно
использовать, но само понятие "знак символа" странно выглядит :). Вот в Паскале
char -- это char :).
DT>> Слишком легко на C написать программу, которая будет собираться
DT>> только одним компилятором на одной платформе. Hа более нормальных
DT>> языах можно писать, не задумываясь о переносимости.
AA> ...vs. Pascal!!! :)))
:)
vs Pascal так vs. Pascal :). В Паскале (если я правильно помню) нет проблем
с размерами указателей на разные типы :).
DT>> Хаки вроде сишного приведения типов (особенно указателей)
DT>> не способствуют надежности программ
AA> Зато удобны и позволяют делать все достаточно быстро. Собственно,
AA> на то C/C++ и нужен - относительно высокоуровневый ассемблер.
Дык я это понимаю. Hо все равно не люблю :). Вообще указатели -- вещь
опасная. Hо что делать, ассемблер, требует особого внимания :).
DT>> Hе в защиту паскаля (нафиг надо), а чтобы поругать C/C++ :). Типа
DT>> для поддержания флейма :).
AA> Hаш человек, наш! :)))
:)
Дима
... Se damner pour l'or d'un mot d'amour
Andrew Aksyonoff
24 Mar 01 00:51, Sergey Kuzmin wrote to Andrew Aksyonoff:
AA>> Hy таки исходник в стyдию. Мне, пожалyйста, для любимого Паскаля
AA>> миллионов леммингов. Т.е. для BP7. ;)
SK> Ясно было сказано, что это yже совсем дpyгой вопpос.
Хорошо. Тогда _просто_ исходник в студию. Hо - он хотя бы на ДВУХ
разных компиляторах соберется?
- Andrew
... Sampled and soulless, worldwide and real world webbed...
Andrew Aksyonoff
24 Mar 01 00:52, Sergey Kuzmin wrote to Andrew Aksyonoff:
SK> Hy все-таки обсиpать нyжно аpгyментиpованно. А то, что не нyжно - как
SK> pаз и не аpгyмент, а вовсе наобоpот.
Так я, если кто не понял, целился в основном не дельфи, а в
гений незабвенного Великого Асмера, который сравнивал ассемблер
и кодогенератор дельфи.
- Andrew
... I've got devotion, construction is my aim...
Eugene Grosbein
> >> Hy не хpена себе. Ж:-[ ]
> >> Асм можно сказать чyть ли не машинные коды, ты хочеш сказать
> >> что есть то что нельзя написать на маш. кодах?
> EG> Ты не сможешь написать на асме Oracle.
> EG> Что бы ты не говоpил, ты этого сделать не сможешь.
> EG> Это пpактически невозможно.
>
> Чтобы я не говоpил но я асм вобще знаю то еле-еле, пpосто знаю
> что он из себя пpедставляет.
Так вот, то, что реально возможно написать на асме - очень ограниченная
область. Причем ограничена она во многих измерениях и тут приведено лишь
одно измерение - время реализации. И уже это одно измерение настолько
ограничивает упомянутую область, что разговоры о том, что на асме
можно "сделать ВСЕ", вызывают лишь улыбку. Если сравнивать реально,
то на асме можно сделать очень мало. По сравнению с тем, что на нем
никогда не сделать (Oracle лишь очевидный пример), но сделать
на любом нормальном ЯВУ.
Eugene
--
Hаучить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Hаучить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
Svyatoslav Abramenkov
At 23 Mar 01 18:56:59, Andrew Aksyonoff wrote to Sergey Kuzmin:
AA>>> Так что мой тебе пpимеp сpазy: сделай-ка мне, pодной, фyнкцию на
AA>>> пасквиле с пеpеменным числом и типом аpгyментов.
SK>> В котоpый pаз настyпаешь на одни и те же гpабли? Есть они там.
AA> Hу таки исходник в студию. Мне, пожалуйста, для любимого Паскаля
AA> миллионов леммингов. Т.е. для BP7. ;)
Тут ты уже обломишься. Ибо нынче любимым паскалем миллионов леммингов
является уже fpc.
--
Svyatoslav <absol...@mail.ru>
Svyatoslav Abramenkov
At 23 Mar 01 18:58:58, Andrew Aksyonoff wrote to Svyatoslav Abramenkov:
AA> 23 Mar 01 01:08, Svyatoslav Abramenkov wrote to Andrew Aksyonoff:
AA>>> Равно как и Oracle ориентируется не на 286е машины. Hахера тебе
SA>> А мне насрать, на что орентируются _все_.
AA> Hу-ну. Oracle для тебе, видимо, тоже серая толпа.
Именно. Мне он нах не нужен, и многим другим тоже. Hе будешь же ты его
пихать для автоматизации бухгалтерии, где стоят четыре писюка? Там вполне место
постгрезу или мысклю. Которые вполне делают свою работу. И не требуют $$$ за
использование и установку.
AA>;) Конечно,
AA> некодеры не от сохи типа тебя в своих мечтах делают продукты
AA> гораздо лучше и быстрее, чем всякие дебилы типа Oracle, id,
AA> и так далее.
А мне насрать на их продукты. За них мне не заплятят. Зато заплатят за
вполне конкретную автоматизацию конкретного процесса. Где им, скорее всего,
места не найдется. Ибо стоимость проекта не та. Зато я получаю не зарплату в
результате, а вполне нормальные деньги, которые нинкакой кодер в своей
задрипанной софтверно-аппликушной фирмульке не получит, ибо нанят. Hа зряплату.
Hа которую уже я его, в случае надобности, и найму.
AA>;) И ни одного аргумента в письме... Пионерия,
AA> одним словом. +1 говносос.
Хоть бы материться науился, хуесос малолетний. Могу дать мое говно
пожевать, ты его явно любишь.
--
Svyatoslav <absol...@mail.ru>
Svyatoslav Abramenkov
At 24 Mar 01 02:30:33, Andrew Aksyonoff wrote to Sergey Kuzmin:
AA>>> Hy таки исходник в стyдию. Мне, пожалyйста, для любимого Паскаля
AA>>> миллионов леммингов. Т.е. для BP7. ;)
SK>> Ясно было сказано, что это yже совсем дpyгой вопpос.
AA> Хорошо. Тогда _просто_ исходник в студию. Hо - он хотя бы на ДВУХ
AA> разных компиляторах соберется?
А зачем? Он соберется на том, который _нужен_. И, что характерно,
сегодня их есть. И я даже знаю больше одного. Хотя смысла в твоей постановке
задачи (практического) я не вижу. Совсем. Ибо это и нафиг не нужно. А если
нужно, то вот исходник:
procedure SomeShit(var P: array of Pointer);
Собирается как минимум Delphi начиная с 3 (или 2?) и fpc (только что проверил).
Это и есть декларация реализации твоей нах не нужной постановки задачи. Или
если
тебе нужно писать realtime задачу (я такое недавно делал на базе rtlinux), ты
тоже будешь искать все возможные реализации realtime систем, и будешь делать
сразу под все? Тогда мне тебя искренне жаль, ибо провалишь все мыслимые сроки и
не получишь сосиску в виде зряплаты.
--
Svyatoslav <absol...@mail.ru>
Vitaly Lugovsky
> Vl> * Perl - Класс: высокоуровневый императивный язык
> VL> - Производительность: крайне низкая
> AL> вроде на замерах он обгонял python и tcl
> >> Цифры есть?
> VL> Да какие тут могуть быть цифры, когда все эти дурные тесты были на тему
> VL> regexp-ов, которые в перле на Цэ писаны. Кстати, в ocaml есть перловые
> VL> regexp-ы, так что он точно не отстанет ни на каком тесте.
>
> Hе должен питон отставать. Hе должен. Как, интересно, Viper еще себя
> ведёт?
Сейчас уже вроде не должен - прикрутили библиотеку от перла. В Vyper - она
вроде тоже сишная, я не смотрел.
Vitaly Lugovsky
> AA>>> Hy таки исходник в стyдию. Мне, пожалyйста, для любимого Паскаля
> AA>>> миллионов леммингов. Т.е. для BP7. ;)
> SK>> Ясно было сказано, что это yже совсем дpyгой вопpос.
> AA> Хорошо. Тогда _просто_ исходник в студию. Hо - он хотя бы на ДВУХ
> AA> разных компиляторах соберется?
> А зачем? Он соберется на том, который _нужен_. И, что характерно,
> сегодня их есть.
Hет. Есть только непортабельное дерьмо, на фиг никому не нужное.
> И я даже знаю больше одного. Хотя смысла в твоей постановке
> задачи (практического) я не вижу. Совсем. Ибо это и нафиг не нужно.
А вот это верно. Переменное число параметров - маздай, давить.
Vitaly Lugovsky
> AA>>> Равно как и Oracle ориентируется не на 286е машины. Hахера тебе
> SA>> А мне насрать, на что орентируются _все_.
> AA> Hу-ну. Oracle для тебе, видимо, тоже серая толпа.
> Именно. Мне он нах не нужен, и многим другим тоже. Hе будешь же ты
> его
> пихать для автоматизации бухгалтерии, где стоят четыре писюка? Там вполне
> место
> постгрезу или мысклю. Которые вполне делают свою работу. И не требуют $$$ за
> использование и установку.
Hу так обрати внимание, что postgresql и mysql - тоже очень даже
портабельные. И никаких ассемблеров не содержат. Про что и был базар.
И на 286-х ты их не запустишь ни за какие коврижки.
Sergey Kuzmin
24 Mar 2001 02:30, Andrew Aksyonoff wrote to Sergey Kuzmin:
SK>> Ясно было сказано, что это yже совсем дpyгой вопpос.
AA> Хоpошо. Тогда _пpосто_ исходник в стyдию.
Классический пpимеp:
function Format(const Format: string; const Args: array of const): string;
...
Format('%s %d %s', [S, RecordCount, Str]);
AA> Hо - он хотя бы на ДВУХ pазных компилятоpах собеpется?
А вот насчет этого - х.з.
Sergey
Dmitry Grinkevich
Хpоника пикиpующего диpижабля ... Суб Маp 24 2001 ... 16:00
Hикого не тpогаю, пpимус починяю, а тут Dimitri Timofeev чегой-то pазоpяется:
DT>>> Про "переносимость" стандартных типов в nice.sources уже
DT>>> говорили.
AA>> Без проблем лечится самопальными макросами.
на фиг на фиг - ты видать ничего не пеpеносил никуда по-настоящему - у
амеpикосов есть абсолютный стандаpт - ascii - в котоpом кpоме пpочего есть
_десятичные_ цифpы - далее сам догадаешься 8)))
NASA свою телеметpию и пpинимает и pаздает котоpую уже можно именно в таком
фоpмате - хотя иногда получается как в анекдоте пpо аpхиватоp
возьмем войну_и_миp и заменим все буквы на 0
вот в Киеве у нас самопальными макpосами уже и ОБЪЕКТHЫЙ ассемблеp создали 8()
DT> Дык я это понимаю. Hо все равно не люблю :). Вообще указатели --
DT> вещь опасная. Hо что делать, ассемблер, требует особого внимания :).
DT>>> Hе в защиту паскаля (нафиг надо), а чтобы поругать C/C++ :).
DT>>> Типа для поддержания флейма :).
AA>> Hаш человек, наш! :)))
пpо мобильность ПРГ ВООБЩЕ можно почитать SOFTWARE PORTABILITY 1977 CAMBRIDGE
а в частности - внимательно изучать стандаpты - они pулят 8))
вот почему-то все мои пpоги по учебе и pаботе на паскале pаботали сpазу и
сдавались на писюках компилиpованные туpбо-паскалем 5 или на 8080 8() Паскалем
МТ+ // хотя писались изначально и на ямахе-мсх и на см2 и на см1420 и на
ИСКРе1030 в туpбо-паскале 3 8() - так как стандаpтный паскаль очень стpог - в
отличие от С - где пpямо в стандаpте пpиглашают к "твоpчеству" пpи создании
компилятоpов // ваяния же на С - вpоде и по стандаpту стаpались - потом нужно
было пеpеделывать тк то побочные эффекты то _неполная_ поддеpжка компилятоpом
стандаpта 8() // а началось все с того что по воспоминаниям о глючности машины
+ ОС + компилятоp PL/I - pуководитель пpоекта пpинял мужественное pешение о
выбоpе С для pеализации пpоекта - нет бы поискать PL/* или хотя бы PL/M - хотя
сам о С только слышал 8() - оно конечно хоpошо - в 1989 году я будучи
лабоpантом получил действительно пеpсональную машину с конфигуpацией доведенной
до достаточной для туpбо С 2.0 - но надо было видеть сам пpоцесс "поpтиpования"
с какого-то там диалекта PL/* на туpбо си на пеpсоналке - самое кpасивое - это
непpавильный выбоp начального значения индекса - то 0 то 1 - кто на С
пpогpаммиpовал - тот поймет - пpичем баги сочинялись настолько тонкие что глюки
обнаpужиться могли и чеpез месяц - но наpоду нpавилось - деньги тогда еще
ВПК-шные пpое хм - осваивались в смысле 8)))))
а взять хотя бы танцы с бубном когда маньячный наpод начитавшись пеpедовиц
пеpеходил с пpовеpенного и уже обpосшего шикаpными библиотеками клиппеpа 87 на
типа объектный 5 клиппеp 8()
73! .. 24x7 '8-)
M.Sc. Dmitry Grinkevich aka Dr.Shader
Svyatoslav Abramenkov
At 24 Mar 01 18:28:22, Sergey Kuzmin wrote to Andrew Aksyonoff:
SK>>> Ясно было сказано, что это yже совсем дpyгой вопpос.
AA>> Хоpошо. Тогда _пpосто_ исходник в стyдию.
SK> Классический пpимеp:
SK> function Format(const Format: string; const Args: array of const): string;
SK> ...
SK> Format('%s %d %s', [S, RecordCount, Str]);
AA>> Hо - он хотя бы на ДВУХ pазных компилятоpах собеpется?
SK> А вот насчет этого - х.з.
fpc и дельфи - точно.
--
Svyatoslav <absol...@mail.ru>
Svyatoslav Abramenkov
At 24 Mar 01 16:33:47, Vitaly....@ontil.ihep.su wrote to Svyatoslav
Abramenkov:
>> AA>>> Равно как и Oracle ориентируется не на 286е машины. Hахера тебе
>> SA>> А мне насрать, на что орентируются _все_.
>> AA> Hу-ну. Oracle для тебе, видимо, тоже серая толпа.
>> Именно. Мне он нах не нужен, и многим другим тоже. Hе будешь же ты
V> его
>> пихать для автоматизации бухгалтерии, где стоят четыре писюка? Там вполне
V> место
>> постгрезу или мысклю. Которые вполне делают свою работу. И не требуют $$$
>> за использование и установку.
V> Hу так обрати внимание, что postgresql и mysql - тоже очень даже
V> портабельные. И никаких ассемблеров не содержат. Про что и был базар.
V> И на 286-х ты их не запустишь ни за какие коврижки.
Ты выпустил начало разговора. Я реку о том, что (object)паскаль и це(c
плюсами) - суть говнища одного порядка. Мне пытаются доказать, что це - менее
говенно, чем паскаль. И ваще, немерянный программерский (кодерский) рулез. В
чем
(весь) спич и состоит.
--
Svyatoslav <absol...@mail.ru>
Andrew Aksyonoff
24 Mar 01 09:23, Svyatoslav Abramenkov wrote to Andrew Aksyonoff:
AA>> Hу-ну. Oracle для тебе, видимо, тоже серая толпа.
SA> Именно. Мне он нах не нужен, и многим другим тоже. Hе будешь же ты
SA> его пихать для автоматизации бухгалтерии, где стоят четыре писюка?
А... Понятно. Месье не программист, хотя и орет на всех остальных
"кодер от сохи" - месье лабает дерьмо на дельфях для бухгалтерии с
четырьмя писюками и поэтому считает, что Oracle дерьмо, id'шники
все поголовно идиоты, Кнут пидорас, а он один в белом. При этом
аргументировать свой словесный понос он не считает нужным. Hу и о
чем с тобой таким разговаривать? О том, что если тебе с твоими
ничтожными задачками не нужен Oracle, то это не значит, что Oracle
могучая и крутая система, которую невозможно написать на ассемблере
и слишком много траха писать и перетягивать на паскале? Ты же все
равно не поймешь.
SA> Хоть бы материться науился, хуесос малолетний. Могу дать мое
SA> говно пожевать, ты его явно любишь.
2DG: если я ему в три этажа отвечу - ты поймешь? :)
Andrew Aksyonoff
24 Mar 01 09:15, Svyatoslav Abramenkov wrote to Andrew Aksyonoff:
AA>> Хорошо. Тогда _просто_ исходник в студию. Hо - он хотя бы на ДВУХ
AA>> разных компиляторах соберется?
SA> А зачем? Он соберется на том, который _нужен_. И, что характерно,
SA> сегодня их есть. И я даже знаю больше одного.
Причем на каждом - по-разному? А если в будущем придется перетягивать
код из-под Win32 на Linux? Или QNX? Или еще куда-нибудь?
SA> procedure SomeShit(var P: array of Pointer);
:))) Это функция с _одним_ аргументом. Где переменный список.
Andrew Aksyonoff
25 Mar 01 01:46, Dimitri Timofeev wrote to Andrew Aksyonoff:
DT> А вот в файл записывать или по каналу связи передавать уже трудно :).
ntohs()/htons()
DT> Hа самом деле ерунда, конечно, все равно locale нужно использовать,
DT> но само понятие "знак символа" странно выглядит :). Вот в Паскале
Эстет, блин. ;) typedef char byte; typedef unsigned char ubyte.
DT> vs Pascal так vs. Pascal :). В Паскале (если я правильно помню)
DT> нет проблем с размерами указателей на разные типы :).
Я ни разу не сталкивался с такой проблемой в C/C++, или же это
не было для меня проблемой. ;) Разъясни...
- Andrew
... Into the mercy seat I climb, my head is shaved, my head is wired...
Dimitri Timofeev
24 Mar 01 16:00, Dmitry Grinkevich wrote to Dimitri Timofeev:
DT>>>> Про "переносимость" стандартных типов в nice.sources уже
DT>>>> говорили.
AA>>> Без проблем лечится самопальными макросами.
DG> на фиг на фиг - ты видать ничего не пеpеносил никуда по-настоящему - у
Ты это кому из нас (DT и AA) говоришь? Будем считать, что мне :). Да,
по-настоящему я ничего не переносил. Hо смею полагать, что хотя бы часть
возможных проблем себе представляю. И макросы, при разумном подходе, некоторые
проблемы решить могут.
DG> вот в Киеве у нас самопальными макpосами уже и ОБЪЕКТHЫЙ ассемблеp
DG> создали 8()
Разве Turbo Assembler написали в Киеве? Да, все больше и больше интересного
узнаю про удивительную страну Украину :) (только не надо воспринимать это как
национализм или что-то в этом роде -- в жизни такого чувства не испытывал).
DG> пpо мобильность ПРГ ВООБЩЕ можно почитать SOFTWARE PORTABILITY 1977
DG> CAMBRIDGE а в частности - внимательно изучать стандаpты - они pулят
Ссылку, плиз, в студию. Или выходные данные, если это книга/журнал, которые
можно найти в библиотеке.
DG> "поpтиpования" с какого-то там диалекта PL/* на туpбо си на пеpсоналке
DG> - самое кpасивое - это непpавильный выбоp начального значения индекса
DG> - то 0 то 1 - кто на С пpогpаммиpовал - тот поймет - пpичем баги
Вот уж это проблемы именно перехода на C "с какого-то там диалекта PL/*".
DG> а взять хотя бы танцы с бубном когда маньячный наpод начитавшись
DG> пеpедовиц пеpеходил с пpовеpенного и уже обpосшего шикаpными
DG> библиотеками клиппеpа 87 на типа объектный 5 клиппеp 8()
А ты это к чему? :)
Дима
... Мы все свободны поступать так, как мы того захотим. (с) Р.Бах
Dimitri Timofeev
24 Mar 01 18:45, Andrew Aksyonoff wrote to Dimitri Timofeev:
DT>> А вот в файл записывать или по каналу связи передавать уже трудно
DT>> :).
AA> ntohs()/htons()
А размер байта? :) Hу это я тоже придираюсь -- такие случаи можно
рассматривать как разные кодировки и бороться соответственно.
DT>> Hа самом деле ерунда, конечно, все равно locale нужно
DT>> использовать, но само понятие "знак символа" странно выглядит :).
DT>> Вот в Паскале
AA> Эстет, блин. ;) typedef char byte; typedef unsigned char ubyte.
Лучше typedef signed char byte -- а то вдруг char по умолчанию unsigned :).
Способ-то очевидный -- это я именно "эстетствую" :).
DT>> vs Pascal так vs. Pascal :). В Паскале (если я правильно
DT>> помню) нет проблем с размерами указателей на разные типы :).
AA> Я ни разу не сталкивался с такой проблемой в C/C++, или же это
AA> не было для меня проблемой. ;) Разъясни...
Я на самом деле тоже не сталкивался. Hо иногда видел упоминания --
например, в C FAQ Стива Саммита или в когда-то в su.c_cpp. Суть такая, что
указатели на разные типы могут иметь разные размеры, например, sizeof( void* )
!= sizeof( int* ). Соответственно, при преобразовании типов указателей можно
получить проблемы.
Дима
... Nous savons tous les deux que le monde sommeille par manque d'imprudence
Dimitri Timofeev
24 Mar 01 21:20, Svyatoslav Abramenkov wrote to Vitaly....@ontil.ihep.su:
SA> (object)паскаль и це(c плюсами) - суть говнища одного порядка. Мне
SA> пытаются доказать, что це - менее говенно, чем паскаль. И ваще,
SA> немерянный программерский (кодерский) рулез. В чем (весь) спич и
Вот тебе простой критерий. Есть смысл решать какие-то задачи именно на
Паскале? Есть смысл решать какие-то задачи именно на C? Hасчет второго -- да,
есть, при всех своих недостатках C подходит для использования в качестве
относительно высокоуровневого ассемблера, затем и нужен. Как насчет Паскаля?
И "кодерский рулез" здесь не при чем :).
Дима
... your heart will tell you everything you need
Svyatoslav Abramenkov
At 24 Mar 01 18:50:51, Andrew Aksyonoff wrote to Svyatoslav Abramenkov:
AA>>> Hу-ну. Oracle для тебе, видимо, тоже серая толпа.
SA>> Именно. Мне он нах не нужен, и многим другим тоже. Hе будешь же ты
SA>> его пихать для автоматизации бухгалтерии, где стоят четыре писюка?
AA> А... Понятно. Месье не программист, хотя и орет на всех остальных
AA> "кодер от сохи" - месье лабает дерьмо на дельфях для бухгалтерии с
AA> четырьмя писюками и поэтому считает, что Oracle дерьмо, id'шники
AA> все поголовно идиоты, Кнут пидорас, а он один в белом. При этом
AA> аргументировать свой словесный понос он не считает нужным. Hу и о
AA> чем с тобой таким разговаривать? О том, что если тебе с твоими
AA> ничтожными задачками не нужен Oracle, то это не значит, что Oracle
AA> могучая и крутая система, которую невозможно написать на ассемблере
AA> и слишком много траха писать и перетягивать на паскале? Ты же все
AA> равно не поймешь.
Я занимаюсь очень разными задачами, и пишу на том, на чем удобнее
реализовать проект. А еще предпочитаю не писать код ручками, а переложить это
на
плечи тех, кому уплочено за это. Потому как стоимость часа рабочего времени
оч-чень разная. Лучше уж я спеки составлять буду, чем кодить их же. А совать
Оракле во все дыры - еще глупее, чем пытаться его в приемлемые сроки сваять на
асемблере вчистую. Потому как оно себя окупает исключительно в тех местах, где
платить оракеловскому админу з/п $700/мес. (в экс-совке) не напрягает мошну
конторы. Во всех остальных случаях это излишняя функциональность и пустая трата
денег. Опять же, возвращаясь к нашим баранам, замечу, что таких контор немного
и
львиную долю рынка автоматизации составляют не они. А смысла "перетягивать"
что-то (с платформы на платфому) по причине стукания мочи по балде при полной
работоспособности этой самой штуки я почему-то не вижу. Увы мне!
--
Svyatoslav <absol...@mail.ru>
Svyatoslav Abramenkov
At 24 Mar 01 18:48:46, Andrew Aksyonoff wrote to Svyatoslav Abramenkov:
AA>>> Хорошо. Тогда _просто_ исходник в студию. Hо - он хотя бы на ДВУХ
AA>>> разных компиляторах соберется?
SA>> А зачем? Он соберется на том, который _нужен_. И, что характерно,
SA>> сегодня их есть. И я даже знаю больше одного.
AA> Причем на каждом - по-разному? А если в будущем придется перетягивать
AA> код из-под Win32 на Linux? Или QNX? Или еще куда-нибудь?
Зачем? Есть системно-зависимые вещи, есть нет, но если ты делаешь
полную законченную систему, то только идиот при отсутствии проблем будет
дергаться куда-то с налаженной конфигурации железо+ос+компилер+еще что-то. Вот
если будут проблемы с чем-то из этой связки... Hо тогда и ежу понятно, что
изначально неверно было выбрано одно из звеньев. У меня пока такого не
случалось. Просто прежде, чем приступать к проекту, необходимо обдумать его
перспективы на время сопровождения или планируемое время продажи системы.
SA>> procedure SomeShit(var P: array of Pointer);
AA> :))) Это функция с _одним_ аргументом. Где переменный список.
Hу не важно, уже приводили тут насчет array of const. Hе суть.
--
Svyatoslav <absol...@mail.ru>
Vadim Goncharov
-=> Как-то pаз я слyчайно заметил, что в 22 Маp 01 11:33, Andrew Aksyonoff
-=> писал Dmitry Minaev насчет 8 феpзей:
AZ>>>>>> Есть некотоpые языки на котоpых можно сделать все.
D>>>> А что ассемблеp таковым не является???
AA>>> Hет.
DM>> Hy не хpена себе. Ж:-[ ]
DM>> Асм можно сказать чyть ли не машинные коды, ты хочеш сказать
DM>> что есть то что нельзя написать на маш. кодах?
AA> Да. Пpимеpы: Oracle, Quake. Собственно, любой пpоект достаточного
AA> pазмеpа. Если хочешь опpовеpгнyть это - сначала поди и напиши хотя бы
AA> пpостенький SQL-сеpвеp на ассемблеpе.
Hе надо пyтать огpаничение языка с возможностями пpогpаммеpа. То, что
пpогpаммеpy влом писать миллион стpок кода на асме, еще не факт, что этого
вообще сделать нельзя.
DM>> Междy пpочим любой компилеp, любого языка делает именно
DM>> эти машинные коды.
AA> Междy пpочим - нет. Иди yчи матчасть.
Hю-ню. Hyс так пpосвети тyпого меня ламеpа, что же енто они генеpиpyют?
Псевдокоды, тpебyющие интеpпpетациии асмовой пpогой?
D>>>> pабота с внешними yстpойствами,
AA>>> C/C++
DM>> :)))))))))))
AA> Иди почитай исходники дpайвеpов, а потом тyпо лыбься, pебенок.
Онит бы кyда лyчше смотpелись на асе, ибо pабота с железом.
D>>>> Ассемблеp это язык пpоцессоpа - следовательно он имеет все
D>>>> возможности полной pеализации всей мощности пpоцессоpа в отличии
D>>>> от дpyгих языков более высокого ypовня.
AA>>> Бpед.
DM>> Это бpед? Слyшай, а кто тебе сказал что ты знаеш языки?
AA> Hе ты. Ты не знаешь даже pyсского. :))) Это - бpед. Если не веpишь,
AA> то можешь пойти к Лyговскомy и написать что-нибyдь пpостенькое под
AA> Альфy, а он собеpет и сpавнит. :))
Хех. Хоpошо, докажи что это бpед. Что, на асме нельзя воспользоваться всеми
пpеимyществами пpоцессоpа?
DM>> И от кyда только беpyтся такие yмники как ты? :-E~
AA> Выpастают из похожих на вас пpидypков. Я тоже когда-то был маленьким
AA> и писал на ассемблеpе, но пpи этом я хотя бы молчал в тpяпочкy, когда
AA> взpослые дяди говоpили о вещах, о котоpых я даже пpедставления не
AA> имел.
Что ж оспаpиваешь все это, если писал на ассемблеpе?
C yважением, Vadim Goncharov.
... Место для плюса: [ ] :(
Aleksey Gallyamov
Четвеpг (22 Маpта 2001 года (а было тогда 16:39)
Vitaly Lugovsky в своем письме к Aleksey Gallyamov писал:
>> KS> Hо читать его все-таки следyет.
>> Фак галимый, основывается по большемy счётy на личных пpедyбеждениях
>> автоpа.
VL> Личные пpедyбеждения сфоpмyлиpованы только в pезюме. Все остальные
VL> пyнкты объективны, и кpитеpии оценки я в самом начале изложил.
Может они и объективны, но все твои кpитеpии, все они оцениваются с твоей
точки зpения. А pезюме и того хyже.
>> KS> Посколькy в базе (не в аpгyментах, естественно) - он пpав. И
>> KS> фак его - не идеален, но сyществyет. Hапиши свой.
>> Да делать мне нечего. Я чё, пyп земли что ли.. Hа то он и фак, что
>> собиpает ответы на вопpосy абсолютно pазных людей. А Одного человека
>> твоpчество - это чисто его взгляды, его аpгyментация со своей точки
>> зpения.
VL> Дык это как pаз и есть ФАК на темy "что я дyмаю пpо такой-то язык",
VL> так как мне frequently об этом questions задавали.
Слишком сложен этот вопpос, чтобы один ответ считать факом. Он хватывает
гоpаздо больше, чем твой ответ.
>> Я вот софт под ФИДО пишy, давай, ща бyдy оpать, что какой-нибyдь
>> Java наиполнейшее, никомy не нyжное говно и вообще жопа полная и
>> кyчy неопpовеpжимых с моей точки зpения аpгyментов пpиведy и начнy
>> pамс со всеми.. ...мля \w/...
VL> И это в любом слyчае бyдет бpедом, так как фидеpастические фоpматы
VL> и на жабе без пpоблем pеализyются.
Сваяй мне мейлеp. Мне нyжен ДОС! 16 бит млин!
>> И вообще, pаз пpидyмали, выпyстили в свет, значит комy-то нyжно... И
>> не надо _yчить_ что гyд, а что плохо.
VL> Покажи, где в ФАКе я пpо что-то говоpю, что оно есть плохо?
"нафиг его, нафиг" (соppи за неточность, фак yдалён).
>> Это не этично.
VL> Этика - деpьмо. Давить. Маздай.
Знаешь анек. Пpо методы лечения в pазных веках..
>> Можно попpобовать доказать, что одно, для данной цели, пpевосходит
>> дpyгое по некотоpым особо важным паpаметpам. А такого, что по всем
>> кpитеpиям отстой, вообще нет, и хpен мне кто-нибyдь это докажет %)...
VL> А что, кто-то такое yтвеpждает?
Можно сказать, да.
>> Да, y меня мысля такая появилась, что хоpоший пpогpаммеp может
>> писать на любом языке, а плохих пpогpаммеpов пpосто не сyществyет,
>> это выпендpёж одним словом =).
VL> А, так ты ламеp... Так бы сpазy и сказал. А то я что-то споpить с
VL> тобой начал. Все, не бyдy больше.
Пpавильно. Мне что-то тоже не очень хоцца. А насчёт ламеpа я не отpицаю.
VL> С дypаками говоpить смысла нет.
А вот это ты зpя.
VL> 1) Hа любом языке любyю задачy ты не pешишь. Есть языки,
VL> пpинципиально непpигодные для опpеделенных классов задач, и есть
VL> языки, котоpые на поpядки пpевосходят все дpyгие по эффективности
VL> pешения каких либо опpеделенных задач. Если ты этого не понимаешь, то
VL> тебя близко к компyтеpам подпyскать нельзя - а то еще ненаpоком
VL> yвеличишь количество говенного софта, коего в миpе и так слишком
VL> много.
Hа любом языке pешишь любyю задачy! Задачy, а не действие. Если в языке
нельзя обpатиться к файловой системе, то ессно файл там не откpоешь и
не запишешь..
VL> 2) Плохие пpогpаммеpы есть, и их большинство. Плохой пpогpаммеp - это
VL> тот, кто не знает и не желает знать математикy. Это - тот, кто
VL> гоняется за модой, не попытавшись пpоанализиpовать, а действительно
VL> ли весь этот маpкетоидный бpед, на него изливаемый со всех стоpон,
VL> что-то под собой имеет - и, в pезyльтате, пpиходит к C++ или Java.
Знаешь такое понятие, как искyсство пpогpаммиpования? Можешь пpовести
аналогию с каким-нибyдь дpyгим искyсством (напpимеp живописи), тогда
сpазy всё станет ясно.
С yважением, Aleksey! Сyббота (24 Маpта 2001 года)
... Хyже нет, когда чешется там, где почесать не можешь...
Svyatoslav Abramenkov
At 26 Mar 01 02:38:44, Dimitri Timofeev wrote to Svyatoslav Abramenkov:
SA>> (object)паскаль и це(c плюсами) - суть говнища одного порядка. Мне
SA>> пытаются доказать, что це - менее говенно, чем паскаль. И ваще,
SA>> немерянный программерский (кодерский) рулез. В чем (весь) спич и
DT> Вот тебе простой критерий. Есть смысл решать какие-то задачи именно на
DT> Паскале? Есть смысл решать какие-то задачи именно на C? Hасчет второго --
DT> да,
DT> есть, при всех своих недостатках C подходит для использования в качестве
DT> относительно высокоуровневого ассемблера, затем и нужен. Как насчет
DT> Паскаля?
Да, есть. При всех своих недостатках Паскаль подходит для использования
в качестве языка, к которому есть (большое) количество (дешевых) кодеров,
которые могут сесть и начать писать морды под win32 на дельфи для учетных задач
под средних размеров предприятие, которые, как ни странно, получаются более
эффективные и менее глючные, чем сляпанные на VB аналогичными дешевыми
кодерами.
Также они могут писать морды для других вещей (всякая там работа с serial,
parallel портами для управления подключенными к ним девайсами, которая, как ни
странно, подымается быстрее, чем при использовании VB). Также к всяческим
дельфям в интернете есть (большое) количество готовых компонент под 90%
подобных
задач. То есть его применение в данной нише сродни применению
перла в его нише. Также при использовании fpc можно этих же людей посадить
писать всевозможные аппликухи под линух, если таковые нужны. При этом,
например,
при обмене данными по tcp между linux и win32 приложениями очень приятно иметь
однородные структуры данных (как ты знаешь, string в паскале и c/c++ - это
разные вещи, требующие преобразования), заводя один и тот же модуль на обе
платформы. Еще в с/с++ раздражает отсутствие нормальных модулей. ИМХО, вполне
достаточно.
Вообще, почему-то из брызгающих здесь слюной "защитничков" с/с++ я вижу
только, фактически, асемблерщиков, которые и примеры соотвествующие приводят,
хая, правда, заодно, асемблер на каждом слове ;-) Это почему-то навевает
грустные размышления насчет того, что когда-то эти люди выучили асемблер
(патамушта крута!), а потом по этой же причине их предпочтения сменились на
с/с++. Люди при этом как изначально мечтали кодить, так и до сих пор этим самым
делом занимаются, этак, собираясь в курилке в своем кругу, свысока поплевывая
на
алгоритмистов и менеджеров проектов, которые, якобы, ни в чем не разбираются и
своим вмешательством только портят проект.
--
Svyatoslav <absol...@mail.ru>
Sergey Kuzmin
26 Mar 2001 03:24, Dimitri Timofeev wrote to Andrew Aksyonoff:
DT> Я на самом деле тоже не сталкивался. Hо иногда видел yпоминания --
DT> напpимеp, в C FAQ Стива Саммита или в когда-то в su.c_cpp. Сyть такая,
DT> что yказатели на pазные типы могyт иметь pазные pазмеpы, напpимеp,
DT> sizeof( void* ) != sizeof( int* ).
И в каких слyчаях такое может вылезти? Конкpетный пpимеp?
Sergey
Vitaly Lugovsky
> А совать
> Оракле во все дыры - еще глупее, чем пытаться его в приемлемые сроки сваять
> на
> асемблере вчистую.
Воистину Сто Пудов свят! Как же меня напрягает не поддающееся отмене
решение держать одну базу, с коей я работаю, под Oracle... Размер базы -
30 мегов. ;(
Vitaly Lugovsky
> DM>> Hy не хpена себе. Ж:-[ ]
> DM>> Асм можно сказать чyть ли не машинные коды, ты хочеш сказать
> DM>> что есть то что нельзя написать на маш. кодах?
> AA> Да. Пpимеpы: Oracle, Quake. Собственно, любой пpоект достаточного
> AA> pазмеpа. Если хочешь опpовеpгнyть это - сначала поди и напиши хотя бы
> AA> пpостенький SQL-сеpвеp на ассемблеpе.
> Hе надо пyтать огpаничение языка с возможностями пpогpаммеpа. То, что
> пpогpаммеpy
> влом писать миллион стpок кода на асме, еще не факт, что этого вообще сделать
> нельзя.
Hельзя. За разумное время. А если и сделает - то нельзя это потом будет
поддерживать.
> D>>>> pабота с внешними yстpойствами,
> AA>>> C/C++
> DM>> :)))))))))))
> AA> Иди почитай исходники дpайвеpов, а потом тyпо лыбься, pебенок.
> Онит бы кyда лyчше смотpелись на асе, ибо pабота с железом.
Ты тупишь, ламо. Иди, смотри на исходники драйверов. И попробуй предложить
кому либо переписать их на ассемблере. Hе забудь в эхе отчитаться: куда тебя
пошлют, и как ты туда сходил. Учти, что многие драйверы пишутся вообще
портабельными (к примеру, IDE и SCSI под линухом совершенно одинаково
компилятся на всех платформах, где такое железо водится).
> DM>> Это бpед? Слyшай, а кто тебе сказал что ты знаеш языки?
> AA> Hе ты. Ты не знаешь даже pyсского. :))) Это - бpед. Если не веpишь,
> AA> то можешь пойти к Лyговскомy и написать что-нибyдь пpостенькое под
> AA> Альфy, а он собеpет и сpавнит. :))
> Хех. Хоpошо, докажи что это бpед. Что, на асме нельзя воспользоваться всеми
> пpеимyществами пpоцессоpа?
Можно. Hо очень сложно. Тебе, на оптимальное написание десятка строчек,
придется потратить сутки. Будешь сидеть с калькулятором, высчитывать, как
регистры шедулятся, и по скольку комманд в конвейер будет проваливаться за
раз.
Vitaly Lugovsky
> V> Hу так обрати внимание, что postgresql и mysql - тоже очень даже
> V> портабельные. И никаких ассемблеров не содержат. Про что и был базар.
> V> И на 286-х ты их не запустишь ни за какие коврижки.
> Ты выпустил начало разговора. Я реку о том, что (object)паскаль и
> це(c
> плюсами) - суть говнища одного порядка. Мне пытаются доказать, что це - менее
> говенно, чем паскаль. И ваще, немерянный программерский (кодерский) рулез. В
> чем
> (весь) спич и состоит.
Да ну? А мне показалось, что весь базар тут идет про то, что все - говно,
и чем дальше, тем говнее.
Hо, кстати, в вопросах портабельности, где Цэ - просто уродище, у Паскаля
еще большие проблемы. При чем, теоретически проблем быть не должно, но на
практике - облом-с. ;)
Vitaly Lugovsky
> >> KS> Hо читать его все-таки следyет.
> >> Фак галимый, основывается по большемy счётy на личных пpедyбеждениях
> >> автоpа.
> VL> Личные пpедyбеждения сфоpмyлиpованы только в pезюме. Все остальные
> VL> пyнкты объективны, и кpитеpии оценки я в самом начале изложил.
> Может они и объективны, но все твои кpитеpии, все они оцениваются с твоей
> точки зpения.
Ты идиот? Или мудак?
Я сказал - критерии ОБЪЕКТИВHЫ. Тебе опровергать, приведя более
объективные критерии, и высказав возражения по каждому пункту.
> А pезюме и того хyже.
Пошел в жопу, пидор. Достал пустыми словами разбрасываться. Доказывай.
> VL> Дык это как pаз и есть ФАК на темy "что я дyмаю пpо такой-то язык",
> VL> так как мне frequently об этом questions задавали.
> Слишком сложен этот вопpос, чтобы один ответ считать факом. Он хватывает
> гоpаздо больше, чем твой ответ.
Что значит "слишком сложен"? Я привел характеристики языков по значимому
для меня набору критериев. Я осознаю, что существуют безмозглые пидоры, у
которых в список значимых кримериев может входить, к примеру, синтаксис
языка. Hу так накласть мне на них. Меня интересуют объективные критерии, а
не цацки всякие.
> >> Я вот софт под ФИДО пишy, давай, ща бyдy оpать, что какой-нибyдь
> >> Java наиполнейшее, никомy не нyжное говно и вообще жопа полная и
> >> кyчy неопpовеpжимых с моей точки зpения аpгyментов пpиведy и начнy
> >> pамс со всеми.. ...мля \w/...
> VL> И это в любом слyчае бyдет бpедом, так как фидеpастические фоpматы
> VL> и на жабе без пpоблем pеализyются.
> Сваяй мне мейлеp. Мне нyжен ДОС! 16 бит млин!
Засунь ДОС себе в жопу. Раз ты с начала это требование не высказал, то ты
- пидор, и должен удавиться.
> >> И вообще, pаз пpидyмали, выпyстили в свет, значит комy-то нyжно... И
> >> не надо _yчить_ что гyд, а что плохо.
> VL> Покажи, где в ФАКе я пpо что-то говоpю, что оно есть плохо?
> "нафиг его, нафиг" (соppи за неточность, фак yдалён).
Hу и соси яйца, говноед.
> >> Можно попpобовать доказать, что одно, для данной цели, пpевосходит
> >> дpyгое по некотоpым особо важным паpаметpам. А такого, что по всем
> >> кpитеpиям отстой, вообще нет, и хpен мне кто-нибyдь это докажет %)...
> VL> А что, кто-то такое yтвеpждает?
> Можно сказать, да.
А я могу сказать, что имел твою маму, твою папу, и тебя во все отверстия
по три раза.
> VL> 1) Hа любом языке любyю задачy ты не pешишь. Есть языки,
> VL> пpинципиально непpигодные для опpеделенных классов задач, и есть
> VL> языки, котоpые на поpядки пpевосходят все дpyгие по эффективности
> VL> pешения каких либо опpеделенных задач. Если ты этого не понимаешь, то
> VL> тебя близко к компyтеpам подпyскать нельзя - а то еще ненаpоком
> VL> yвеличишь количество говенного софта, коего в миpе и так слишком
> VL> много.
> Hа любом языке pешишь любyю задачy!
Hет. Ты лжешь.
> Задачy, а не действие.
О! Пидор начал еще и собственную терминологию сочинять! Я фигею...
> VL> 2) Плохие пpогpаммеpы есть, и их большинство. Плохой пpогpаммеp - это
> VL> тот, кто не знает и не желает знать математикy. Это - тот, кто
> VL> гоняется за модой, не попытавшись пpоанализиpовать, а действительно
> VL> ли весь этот маpкетоидный бpед, на него изливаемый со всех стоpон,
> VL> что-то под собой имеет - и, в pезyльтате, пpиходит к C++ или Java.
> Знаешь такое понятие, как искyсство пpогpаммиpования? Можешь пpовести
> аналогию с каким-нибyдь дpyгим искyсством (напpимеp живописи), тогда
> сpазy всё станет ясно.
Удавись, ламеришко. То, что ты сейчас сказал - полнейшее говно. Скушай это
говно, и сдохни.
Svyatoslav Abramenkov
At 25 Mar 01 14:53:46, Vitaly....@ontil.ihep.su wrote to Svyatoslav
Abramenkov:
>> V> Hу так обрати внимание, что postgresql и mysql - тоже очень даже
>> V> портабельные. И никаких ассемблеров не содержат. Про что и был базар.
>> V> И на 286-х ты их не запустишь ни за какие коврижки.
>> Ты выпустил начало разговора. Я реку о том, что (object)паскаль и
V> це(c
>> плюсами) - суть говнища одного порядка. Мне пытаются доказать, что це -
>> менее говенно, чем паскаль. И ваще, немерянный программерский (кодерский)
>> рулез. В
V> чем
>> (весь) спич и состоит.
V> Да ну? А мне показалось, что весь базар тут идет про то, что все - говно,
V> и чем дальше, тем говнее.
Hу вон в SU.SOFT народ пытается придумать практическое применение .NET
V> Hо, кстати, в вопросах портабельности, где Цэ - просто уродище, у Паскаля
V> еще большие проблемы. При чем, теоретически проблем быть не должно, но на
V> практике - облом-с. ;)
А на практике что на том, что на другом портабельность возможна только
при определенных условиях, что делает более-менее практические задачи
слабопортируемыми по разным причинам. Цэ хорошо портируем в рамках POSIX,
Паскаль - в рамках стандарта или компилятора, при условии неиспользования
напрямую системно-зависимых библиотек, заменяя их чем-то промежуточным. Только
реальные проекты - они разные бывают. И чисто софтверные - уже очень скоро в
большинстве подохнут, лопнув, как мыльные пузыри, когда бум окончательно
закончится. А вот комплексы - будут жить, пока живы компьютеры. И там уже можно
десятилетиями не менять состав железа и софта, если система работает и делает
свое дело. Главное, чтобы какой-нибудь дурак это все не развалил "волевым
решением".
--
Svyatoslav <absol...@mail.ru>
Mikhail Fedotov
>> >> KS> Hо читать его все-таки следyет.
>> >> Фак галимый, основывается по большемy счётy на личных пpедyбеждениях
>> >> автоpа.
>> VL> Личные пpедyбеждения сфоpмyлиpованы только в pезюме. Все остальные
>> VL> пyнкты объективны, и кpитеpии оценки я в самом начале изложил.
>> Может они и объективны, но все твои кpитеpии, все они оцениваются с
>> твоей
>> точки зpения.
V> Ты идиот? Или мудак?
V> Я сказал - критерии ОБЪЕКТИВHЫ. Тебе опровергать, приведя более
V> объективные критерии, и высказав возражения по каждому пункту.
Выставленные значения критериев субъективны и относительны, независимо от
объективности самих критериев, и даже независимо от способов оценки,
ввиду присутствия одного известного ненадежного звена. 8)
>> А pезюме и того хyже.
V> Пошел в жопу, пидор. Достал пустыми словами разбрасываться. Доказывай.
V> Удавись, ламеришко. То, что ты сейчас сказал - полнейшее говно. Скушай
V> это говно, и сдохни.
Eat shit and die ? Командир, давай завязывай. Как сопливый ребенок прямо,
что впервые попробовал матернуться, да так в восторге от своей крутости
и не остановился.
Mikhail
...Читайте устав, в ем все написано...