Классы как в паскале. Почему???

что в нём сломали после 0.8.8 ?

Версия 0.8.8 успешно компилировалась с помощью tcc, и после этого работала. Нынешний компилируется, но уже не работает.

PS: Генерируемые исходники самого nim не должны включать ничего кроме nimbase.h (никаких string.h и тп.) А то при попытке использовать другой компилятор (отладка) приходится править все сишные исходники.

PPS: скомпилированный с помощью tcc компилятор nim ведёт себя (ход вызовов процедур) не так, как скомпилированный с помощью gcc. Почему — понять не смог. У tcc отладочная информация генерируется плохо; локальные переменные в debug отсутствуют, временами не понятно, какая процедура в данный момент выполняется.

PPPS: пытаюсь довести tcc до возможности скомпилировать linux 2.4.37 (без изменения исходников). Версия 2.4.26 компилируется и работает, но её не могут собрать современные gcc

http://ooc-lang.org/

Интересный язык. Напомнил скалу.

Классы как в паскале

Сначала был написан на FPC (до 0.9). Потом pascal-исходники перестали поддерживать. Поэтому — subj есть неисжитое наследие. Однако для меня классы в нём как в go :-)

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

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

основные аргументы против лиспа все еще связаны с отсутствием синтаксиса

И не надейся. Синтаксис это самая незначительная из претензий к скобкоте. У скобкоты и кроме отсутствия человеческого синтаксиса полно проблем: дебильная (динамическая, но при этом не утиная) система типов, наличие макросов (привет, грязные хаки, давно забаненные в мире сишечки), отсутствие приличного стандарта (зоопарк из говна), бардак с модулями и неймспейсами, отсутствие приличных IDE, отсутствие библиотек, отсутствие разделения на expressions и statements, бардак с раздельной компиляцией (некоторые схемки в нее умеют, но у них свои закидоны).

Если вдруг завтра появится лишпик с человеческим синтаксисом, например, воскресят R-Lisp или еще что подобное, говном лишпик быть не перестанет ни на секунду.

на том основании, что у них синтаксис похож.

Семантика всех Виртовских языков весьма похожа, различия незначительны. А не-Виртовские языки не заслуживают никакого внимания.

Не синтаксис, а идеи.

Какие такие идеи?var x : int = 3;Вроде nim а вроде и pascal. Ну да, в паскале нету let, ну так он нахрен не нужен. В паскале нету fallthrough в case, тут его тоже нету. Зато в паскале не нужно писать множество of, одного вполне достаточно. Заменили begin/end отступами, это ужас. Не смог найти аналог absolute (или union в C).

Ну да, в паскале нету let, ну так он нахрен не нужен.

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

паскале нету fallthrough в case, тут его тоже нету.

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

Зато в паскале не нужно писать множество of

Не понял, да и не помню я паскаль уже.

Заменили begin/end отступами, это ужас

Согласен, это питон постарался.

Не смог найти аналог absolute (или union в C).

Наверное его и нет.

Так его вроде нигде нет кроме сей и плюсов, и он нужен очень редко.

Признаюсь, я дремуч в языках в том смысле что кроме плюсов, паскаля, ассемблеров толком никаких больше языков не знаю. Поэтому возможно вы правы в том, что кроме плюсов и сей этого больше нигде нет, но fallthrough позволяет иногда писать элегантный код. Мне сложно от этого отказаться.

Отсутствие absolute весьма печально. Вроде нет никаких проблем его добавить, непонятно почему разработчики этого не делают.

Я ведь не рассуждаю зачем используется let, я просто хочу сказать что его ценность нулевая. В чем проблема написать const a : int = f(y); От каких ошибок призван защитить этот оператор?

const-выражения в ниме, насколько я понял, вычисляются во время компиляции, так что вероятно let тут аналог паскалевого const.

Отсутствие absolute весьма печально. Вроде нет никаких проблем его добавить, непонятно почему разработчики этого не делают.

Стоит спросить на #nim, там разработчики активно общаются и делятся своими мыслями, вероятно причина есть, но мне она неизвестна.

Менюха на сайте напомнила КонтрСтрайк

Программирование в машинных кодах даёт абсолютную власть над миром :)

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

Сторонние библиотеки - это, на создание чего в одиночку среднестатистическому программисту понадобилось бы несколько веков усердного труда, а какому-нибудь Яндексу в полном его составе - ну, десяток лет от силы, да :)

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

ТНБ бросает монетку и выносит вердикт

Угадал

Ну да, в паскале нету let

почти, with :-D

let это присвоение, with - scope visibility. Как вам такая мысль в голову пришла?

эйфель

Низкоуровневая функциональщина это /0

починил

Вау, новый язык программирования!

что-то ржу

Нет

да. потому, что язык машинных команд — императивен, а всё что далеко ушло от языка машинных команд — не является низким уровнем, по определению.

Образец высера тролля. Зачем всякую гадость сюда тащить?

Как вы определяете «низкоуровневость»? Понятно что все парадигмы выводимы из императивной, но где критерий что «низкоуровневое» а что нет?

лол

Как вы определяете «низкоуровневость»?

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

а, так вы из этих. ок.

способно очевидным для читателя программы образом в него транслироваться

Ну это зависит от читателя, для некоторых и printf - магия. И потом, обобщенное программирование например относится к классу императивных парадигм, однако никоим образом взглянув на шаблон вы не сможете понять во что это потом скомпилируется.

отсутствие сборщика мусора

Критерий так себе. К парадигме не относится вообще. Существует в куче императивных языков.

У меня пока складывается только один критерий - наличие компилятора. Если для языка есть только интерпретатор то он не может быть низкоуровневым.

Если для языка есть только интерпретатор то он не может быть низкоуровневым.

Forth

Не вижу противоречия.

относится к классу императивных парадигм

далеко не всякая императивщина низкоуровнева

однако никоим образом взглянув на шаблон вы не сможете понять во что это потом скомпилируется.

в С++ это практически очевидно

К парадигме не относится вообще.

низкоуровневость — вопрос реализации, а не парадигмы. для синтаксиса ассемблера x86 можно написать компилятор, который сделает этот синтаксис высокоуровневым языком (например, транслятор асм х86->асм arm). но для некоторых парадигм невозможно в принципе написать низкоуровневый компилятор для любой платформы, использующей микроэлектронные схемы, то есть, для любой реально существующей ЭВМ.

Существует в куче императивных языков.

они все высокоуровневые

для форта есть компилятор на форт-машины. на тех платформах — он низкоуровневый. на х86 — это высокоуровневый язык.

для форта есть компилятор на форт-машины

Бгг. Какой ты всё-таки упоротый баран.

а, так и вы из дурачков? ну ок.

Так ты не балаболь тут, а посмотри на ATS.

посмотрел. там даже указателей нет => ни о какой низкоуровневости (даже с натяжкой) для распространённых аппаратных платформ речь идти не может.

Не видишь противоречия в том, что функциональщиной называют императивный язык?

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

Указатели ненужно.

указателей нет

Продавай свисток

ATS has a basic pointer type called ptr. This is a non-dependent type and is the equivalent to a void* in the C programming language. It also has a dependently typed pointer type that is indexed over an addr sort (sorts are the types of type indexes) that represents the address of the pointer

в С++ это практически очевидно

Очевидно тут только то что вы не понимаете о чем рассуждаете.

низкоуровневость — вопрос реализации, а не парадигмы.

BINGO! Но это вы пытались привязать низкоуровневость к императивщине.

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

Например? И, сдается мне, что такие парадигмы вообще тогда не смогут быть реализованы на любой реально существующей ЭВМ.

они все высокоуровневые

Как управление ресурсами относится к уровневости языка? Ничего что для C++ есть библиотеки реализующие GC?

Gforth uses GCC to compile a fast direct or indirect threaded Forth.

Gforth uses GCC to compile a fast direct or indirect threaded Forth.

Интерпретация или машкод - не так важно. Я не встречал общепринятого определения термина «низкоуровневый язык», но, если бы оно существовало, там наверняка было бы что-то о компактности и предсказуемости рантайма.

Очевидно тут только то что вы не понимаете о чем рассуждаете.

это вы плохо понимаете механизм действия шаблонов и то, что они раскрываются в готовый код весьма прозрачно.

в

template<class T> T func(T a, T b){
  return a*a + b*b;
}

auto x = func<int64_t>(1, 2);

весьма тупо раскроется в:

int64_t func(int64_t a, int64_t b){
  return a*a + b*b;
}

BINGO! Но это вы пытались привязать низкоуровневость к императивщине.

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

Например?

например, функциональная. указатели с ней малосовместимы, а без поддержки указателей (не ссылок, а именно указателей), практически нереально написать близкий к аппаратуре код для современных процессоров

Ничего что для C++ есть библиотеки реализующие GC?

С/С++ — это высокоуровневые языки, их только с большой натяжкой можно назвать низкоуровневыми

какая разница? указатели — неотъемлемая часть низкоуровневого кода на всех архитектурах, обладающих хоть сколько-нибудь заметным объёмом памяти. отсутствие указателей не делает язык ни плохим, ни хорошим. просто, он становится высокоуровневым.

откуда это? я в мануале этого не нашёл.

А при чем тут int64? Мы про шаблоны говорим. Я могу записать func<MyClass>(x,y) и ломайте голову во что это превратится.

функциональная парадигма не позволяет писать низкоуровневый код на процессорах или микроконтроллерах массового применения.

GCL позволяет но вы сомневаетесь.

поддержки указателей, практически нереально написать близкий к аппаратуре код для современных процессоров

CFFI
Пишите сколько угодно. Там сложность в другом, при одинаковых аргументах функция должна возвращать одинаковые значения. Или, другими словами, отсутствие понятия времени.
И чего вы в указатели уперлись? Я вам сейчас страшную тайну открою, в микроконтроллерах с объемом памяти в десятки килобайт код, как правило, пишется так что вся память исключительно статическая, даже стек. Это у вас гигабайты, а когда памяти 16к за malloc руки с корнем отрывают :)

А при чем тут int64? Мы про шаблоны говорим.

шаблоны могут с любыми типами работать, и с примитивными тоже.

Я могу записать func<MyClass>(x,y) и ломайте голову во что это превратится.

MyClass func(MyClass a, MyClass b){
  return a*a + b*b;
}

если у класса определены оператор* и оператор+ с правильной сигнатурой, то в тоже и превратится:

int64_t func(int64_t a, int64_t b){
  return a*a + b*b;
}

GCL позволяет но вы сомневаетесь.

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

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

а когда памяти 16к за malloc руки с корнем отрывают

не отрывают. там malloc обычно попросту не работает: для динамической памяти ОС нужна.

CFFI

это же лисп. он вообще мультипарадигменный. на лоре проскакивала как-то новость про ОС написанную на одном из диалектов лиспа. заглянули в код — а там тот же ассемблер, только со скобочками. то есть, забавно, конечно, но к функциональной парадигме это никакого отношения не имеет, так и по вашей ссылке.

А с чего вы взяли что мои * и + умножают и складывают? И зачем вы мне все время ваш int64 подсовываете? Может мой класс - обертка над (char*), и это вам еще крупно повезло если так.

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

Только если писать на ассемблере. Для плюсов достаточно ссылок. Память ведь статическая.

для динамической памяти ОС нужна.

Я тут чаем поперхнулся, нельзя же так. В биосах, по-вашему, malloc'и не работают? Не сомневайтесь, работают еще как.

а там тот же ассемблер, только со скобочками

Да при чем тут ассемблер? pointers in lisp