идеальный язык программирования , каким он должен быть?

Цитата B.V. @ 23.10.06, 07:48

Ну и что же ты не пишешь на asm'е? Трудновато?

А ты готов любую задачу решать на C++?

Цитата Ho Im @ 23.10.06, 07:50

Хронически ниасиливающим — там очинь многа букаф

Букафф там просто чудовищное количество, но очень много конструктива (особенно вначале и ближе к концу). Я бы сказал, что даже как-то необычно для LOR'а.
B.V., в основе Unix-систем C, а не C++, а это, согласись, разные вещи.

Цитата B.V. @ 23.10.06, 08:02

Не помешает.

У меня как у Дрункарда, перманентное столетие.

Добавлено 23.10.06, 08:09

Цитата linuxfan @ 23.10.06, 08:04

Букафф там просто чудовищное количество, но очень много конструктива (особенно вначале и ближе к концу). Я бы сказал, что даже как-то необычно для LOR'а.

А давай книгу выпустим?

Цитата linuxfan @ 23.10.06, 08:04

А ты готов любую задачу решать на C++?

Практически любую, так как

Добавлено 23.10.06, 10:44

Цитата linuxfan @ 22.10.06, 22:45

Цитата (B.V. @ Вчера, 23:38)
Потому что это самый мощный язык из всех существующих.

В чем его мощь?

его мощь в мультипарадигменности

Добавлено 23.10.06, 10:45

Цитата B.V. @ 22.10.06, 20:02

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

Бьярн как раз таким образом и создавал С++
комбинируя и пихая туда, все самое вкусное

Добавлено 23.10.06, 10:46

Цитата impik777 @ 22.10.06, 09:25

Добавлено Вчера, 13:05

Цитата (best_lamer @ 12.10.06, 10:02)
По САБЖу
Идеального нет! И быть не может впринципе. Ибо идеальный должен учитывать все эти подходы а именно:
1) Процедурное программирование
2) Объектно-ориентированное программирование
3) Функциональное программирование
4) Логическое программирование
т.е. такой язык говоря языком простым должен быть повернут и в сторону машины и в сторону человека одновременно! А это невозможно. Пока...


Тут к слову, в С++ есть пока только 1 - 3 пункты
(думаю объяснять не надо)

Добавлено 23.10.06, 10:53
Я думаю к идеальному языку надо:
1 взять текущий стандарт С++
2 прибавить безопасность Java
3 добавить возможности изменения синтаксиса Форта
пока думаю так
Добавлено 23.10.06, 10:55

Цитата linuxfan @ 22.10.06, 22:45

Ну, так надо создать язык мощнее и совершенние C++, ввести его в массы - т.е. потратить миллиарды долларов на рекламу и внедрение продукта на рынох.

сначала надо переписать большое кол-во программ с С++
на этот самый "более мощный и совершенный"

С++ чем-то похож на Винду,
уж слишком он распостраненный
чтобы быстро исчезнуть

Сообщение отредактировано: impik777 - 23.10.06, 10:59

Цитата impik777 @ 23.10.06, 10:44

1 взять текущий стандарт С++

Опять C++... Да отойди ты от C++, глянь на другие языки.

Цитата impik777 @ 23.10.06, 10:44

сначала надо переписать большое кол-во программ с С++
на этот самый "более мощный и совершенный"

Зачем?

Цитата impik777 @ 23.10.06, 10:44

чтобы быстро исчезнуть

Я об его исчезновении не говорил.

Цитата B.V. @ 23.10.06, 11:04

Зачем?

Слишком много программ поддерживаются на С++, бросить их просто так нельзя
так как слишком много надо будет переписать

взять тот же Office(правда там Базика тоже много)

или Дум с Квакой которые до сих пор пишутся на ЧИСТОМ Си
та же Винда

Переписать их полностью заново, слишком трудно,
да и бессмысленно
слишком уж народ привык к ним

Добавлено 23.10.06, 11:44

Цитата B.V. @ 23.10.06, 11:04

Опять C++... Да отойди ты от C++, глянь на другие языки.

Я уже писал, что пользуюсь как минимум четырьмя, да и другие знаю

например
VB, C\C++, Паскаль/Дельфи, Java, Lua, Асм(немного),Форт смотрел

просто в С++ самый мультипарадигменный,
это единственное , что удобно у него,
а так

например для инета я использую только Java
для игровых скриптов Lua
для небольших прог с хорошей интеграцией в Office - VB

Я иногда, когда лень накатывает, вообще представляю себе программирование будущего так : скачал из инета нужные библиотеки, пара щелчков - и они прикручены к проекту, остается только нарисовать интерфейс, а можно выбрать из пары тысяч готовых шаблонов... нда, жуткая картина

И опять очень тонкие особености компилеров

typedef unsigned long long __m64;
class m64
{ __m64 ___m64;
public:
m64 (__m64 m64)  { ___m64 = m64; }   //convert from __m64 to M64
operator __m64() { return  ___m64; } //convert from M64 to __m64
};
inline m64 operator << ( m64 m1 , int m2 )
{
    return  (_m_psllqi( m1 , m2 ));
}
 
extern "C" {
int __cdecl printf(const char *, ...);
void __cdecl main ()
{
 m64 a = 0x1234567800ABCDEF;
 printf ("%X %X" , a << 4);
}
}

Ественно для INTEL C++.

Добавлено 23.10.06, 12:12
и конечно - без всяких хедеров.
на выходе компилера получаем

        movq      mm0, QWORD PTR _2il0floatpacket$1             ;17.6
        movq      QWORD PTR [esp], mm0                          ;17.6
        movq      mm1, QWORD PTR [esp]                          ;18.20
        psllq     mm1, 4                                        ;18.20
        movq      QWORD PTR [esp+8], mm1                        ;18.22

Добавлено 23.10.06, 12:18
очевидный незачот - активно юзаеться стек. как сделать чтоб аргументы для операторов передовались как указатели?

При чём здесь язык программирования? Хочешь убедить в уникальности и волшебности asm-а? У тебя ничего не выйдет

Цитата impik777 @ 23.10.06, 10:44

его мощь в мультипарадигменности

заметь — мультипарадигменность не есть всепарадигменность. Некоторые вещи C++ все-таки нативно не очень хорошо держит.
Вообще, в качестве почти идеальной я бы взял связку C&C++&Lisp+всякие domain-specific языки ((x)html, sql, maxima, ...).

Цитата impik777 @ 23.10.06, 10:44

Я думаю к идеальному языку надо:
1 взять текущий стандарт С++
2 прибавить безопасность Java
3 добавить возможности изменения синтаксиса Форта
пока думаю так

Берем лисп. Пишем парсер, который из исходного текста на паскале, C++, C, Java, C#, форте, etc генерирует лисповский код. Называем это мега-языком. Вот и весь рецепт.

Сообщение отредактировано: mo3r - 23.10.06, 14:58

Цитата BugHunter

При чём здесь язык программирования?

А езык програмирования (с++) - оказываеться тут не при чем, ИДЕАЛЬНЫЙ КОМПИЛЕР рулит. на М$-явочном пришлосьбы больше телодвижений сделать чтобы перегрузить операторы на SIMD расширения.

Цитата BugHunter

Хочешь убедить в уникальности и волшебности asm-а?

кого себя? я в этом убежден. тока чесслово не люблю я ентот асм. Ламать люблю а строить на нем чето - нет уж - увольте.
зы
Просто хотелось чтоб сё было кросиво вот и спрасил.

Добавлено 24.10.06, 00:51
з.з.ы
а gc++ - шумный слифф

Цитата LuckLess @ 30.06.06, 10:09

.. ты говоришь просто что на форте все записи короче выходят... вот сравнимс..

а причём тут длина некомпилированного кода ?
Или вам на скорость работы и размер конечного бинарника насцрать?




Я считаю что wormball занялся никому ненужной задачей! IMHO!!!

И удобней и понятней чем C++ я вообще не представляю ЯП...

Цитата .WiDE C @ 24.10.06, 08:41

И удобней и понятней чем C++ я вообще не представляю ЯП...

А какие ЯП ты знаешь кроме C++?

Цитата impik777 @ 23.10.06, 11:37

Слишком много программ поддерживаются на С++, бросить их просто так нельзя

Можно создать конвертер из C++ в "идеальный язык".

Цитата .WiDE C @ 24.10.06, 08:41

И удобней и понятней чем C++ я вообще не представляю ЯП...

Я тебе подскажу - VB, куда уж понятней и удобней.

Цитата impik777 @ 23.10.06, 10:44

Я думаю к идеальному языку надо:
1 взять текущий стандарт С++
2 прибавить безопасность Java
3 добавить возможности изменения синтаксиса Форта
пока думаю так

И как же в С++ добавить "возможности изменения синтаксиса Форта"? Да и тебе не кажется, что большинству С++ не нужен, зачем же усложнять компилятор?

Цитата mo3r @ 23.10.06, 14:56

Берем лисп. Пишем парсер, который из исходного текста на паскале, C++, C, Java, C#, форте, etc генерирует лисповский код. Называем это мега-языком. Вот и весь рецепт.

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

Цитата .WiDE C @ 24.10.06, 08:41

Цитата (LuckLess @ 30.06.06, 13:09)
.. ты говоришь просто что на форте все записи короче выходят... вот сравнимс..

а причём тут длина некомпилированного кода ?

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

Цитата .WiDE C @ 24.10.06, 08:41

Или вам на скорость работы и размер конечного бинарника насцрать?

Так ведь еще не придумали ЯП, который удовлетворяет обоим требованиям.
По размеру бинарного кода однозначно рулят асм и Форт(реализация на Форте Паскаля занимает десяток килобайт-это со встроенной Форт-системой!). По скорости опять же асм, точнее человек Да и Форт незначительно от него отстает, за счет малого размера, соответственно более хорошего использования кеша процессора.

Цитата .WiDE C @ 24.10.06, 08:41

Я считаю что wormball занялся никому ненужной задачей!

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

Цитата .WiDE C @ 24.10.06, 08:41

И удобней и понятней чем C++ я вообще не представляю ЯП...

Да навалом, те же Модула 2 и Паскаль, Бейсик неплохо развивается. А самый простой и понятный - естественно асм, хотя самым удобным его не всегда назовешь

Цитата AndNot @ 24.10.06, 12:39

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

Не совсем так. Алгоритмические языки (C, Pascal, BASIC) позволяют описывать алгоритм из более-менее крупных блоков, не заботясь о числе доступных регистров, состоянии стека и проч, а на асме вычисление выражения ((a+b)*(c+d)/(e+f))^2 выглядит... неестественно для человеческого восприятия, да и при написании можно «сесть в лужу» (вот забудешь, что при умножении и делении dx/edx задействуются -- и приехали). В более-менее длинных процедурах я такие извраты применял, чтобы как можно реже к памяти обращаться, что спустя две недели поиск ошибки начинался с 20-минутной медитации на тему «а почему это вообще работает?!»