Самые уродливые ЯП

эта, как там, «сперва добейся», да?

Нет.
Это басня Крылова.

Меня Андродофоны по настоящему достали.

И когда сын захотел телефон я отдал ему свой.

Заменой очень доволен.

Привыкание заняло пару дней.

Из софта не хватаетскайпа, который пока только для 10.1
На z10 10.1 вроде через неделю будет официально доступен.

vimscript

Да, от дьявола.

bash

Он если не прекрасен, то очень близок к этому.
Вы просто его не приняли, не играли на его тонкой душевной арфе :)

php, bash, js

во, сразу видно школоту, кто сказал ява - бббкккххххихихихи
указатели в си - аааааахахахахаха

на самом деле плюсы, ужасней кода не видел и не увижу

Я начинал изучать Java и её синтаксис вызвал у меня страшную боль.

1C

PHP, C++, Java, Python, Ruby, JS, C#

Работать с голой памятью в сишке куда приятнее, чем в pascal или haskell.

haskell

нет разницы, разве что castPtr-ов побольше. Просто в haskell желательно до этого не опускаться.

Если придираться к мелочам, то все языки кроме Ruby. А так, все вполне писабельны.

Я начинал изучать Java и её синтаксис вызвал у меня страшную боль.

Радуйся, у тебя есть шансы стать программистом!

Ну да, я неосилятор сей. Я больше по высокоуровневым :)

Что именно? Блоки плюсовые, вызов через точку вообще почти во всех языках работает.

MapBasic - эталон проприетарной ужасности.

PHP - зачем нужен этот шаблонизатор так и не понял. Была эпичная статья про ужасы этого DSL for WEB.

JavaScript - другая сторона ужасности. Бедный рантайм, ад типов, много реализаций и _все_ они «кривые».

C изучается за пару днуй и осваивается за неделю-две.

На уровне хелловорлда.

Указатели кажутся мне вершиной ужаса программиста.

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

php

от это точно, лорчую. С виду — няшная сишечка, а на самом деле, НЁХ забитая граблями чуть менее чем целиком. Любая программа на этом ЯП будет работать, но только Патрег знает КАК.

Но арифметика указателей — достаточно удобный инструмент в своей нише.

проблема в том, что даже когда без неё вполне можно обойтись - без неё в C, и что самое страшное,в якобы высокоуровневом C++ - без неё нельзя обойтись

4.2 же!

Зачем тебе в C++ указатели?

bash - мне стыдно за юникс

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

знаю, ты покажи мне пример использования transform без итераторов

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

Наверное, дело вкуса. Я понял вопрос буквально: мне не нравится его, эээ, синтаксис.

ага - работа на кого-то

работа - это работа, а хобби - это хобби.

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

всяко бывает

vimscript вообще один большой впорос: «ЗАЧАМ»?! Нельзя было сразу написать биндинг к питону?

к сожалению, тогда ещё не было питона. Т.е. vim и питон появились примерно одновременно, в конце 80х начале 90х годов прошлого века. Естественно Мооленаар не в курсе был о только-что придуманном языке, да и пихать туда недоделанную бету было необоснованно. К тому-же, изначально в Vim язык скриптов был не первой и не десятой фичей, это не emacs.

знаю, ты покажи мне пример использования transform без итераторов

int a[] = {1,2,3,4};
transform( a, a + 4, a, [](int x){ return x+1; } );

жалста, кстати range ляжет на него тоже чуть ли не 1:1, достаточно сделать 3 «alias» в виде перегруженных операторов:

* - front
++ - pop_front
!= - !empty

работа - это работа, а хобби - это хобби.

работа на себя всяко приятнее

regex красивый.

BF простой и красивый, а вот программы на нём убогие.

мне просто жалко тратить драгоценные годы своей жизни на изучение этого страшилища

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

К примеру, возможность прямого доступа к памяти является достоинством, ибо позволяет получить максимальную скорость рантайма. Если это не нужно, можно прямой доступ инкапсулировать в класс/шаблон (STL юзать, Qt, да хоть самому навелосипедить). Но быдлокодер будет юзать прямой доступ там, где этого не нужно. Разве это баг языка?

То, что нет модульности, во первых неправда (есть namespace), во вторых, даже в сишечке никто не мешает тебе делать по одному модулю в файле. Если ты напихал Over9000 модулей в файл, или наоборот, то разве это баг ЯП? Нет. make(cmake тоже) будет тупить и на любом другом ЯП, в котором ты такое сделал.

Ну и вообще вся статья написана каким-то фанатегом…

Да, особенность языка, но всем известная.

то есть таки да?

boost же, и ACE.

сторонние библиотеки же, да в 11-м чуть перетянули, стало поприятственней

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

будто что-то принципиально новое

Ну и вообще, шаблоны в C++ - это Тьюринг-полный язык, сам по себе

бинго! именно что _сам_по_себе_, синтаксическая конструкция прилепленная сбоку! /тут для сравнения тирада про лисповые макросы/

можно например во время компиляции, заставить компилятор посчитать факториал числа

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

какая разница, где обьявлены типы - в ядре языка, или в библиотеке

он не об этом, в библиотеке они тоже не high level

Да сообщения об ошибках порой выходят большие,

ещё какие

но это расплата за высокую производительностью.

А какое она к этому имеет отношение?

и для вектора - люди используют вектор. c-array нужен только там, где нужны POD типы

почему это нельзя было реализовать более однородно? И где, таком случае, нужен также упомянутый printf?

что сказать, неосилятор.

Там же расписано, в чём дело.

«No binary implementation rules» - это скорее плюс, а не минус

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

в современных IDE все эти проблемы давно решены.

парсерами, любовно жрущими ресурсы. Костыли-костылики. Уж кем нужно быть, чтобы не признавать ублюдочность хедеров в 21 веке? Хорошо хоть ребята с clang вроде как взялись реализовывать, авось и будет более-менее нормальная модульность (сколько там десятилетий назад оно появилось в других языках?)

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

и тут опять лиспомакросы

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

есть мнение, что далеко не всегда. Тот же D лишён многих детских болезней плюсов

(есть namespace)

если namespaces это модули, то я балерина

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

компилятор не бьет за это по рукам, вот что мешает.

Суть модульности ещё и в том, что тебе не нужно на каждый чих в инклюде пересобирать половину проекта.

Тот же D лишён многих детских болезней плюсов

о болезнях D можно будет говорить только тогда, когда на нем будут писать больше чем полтора анонимуса, это не считая общей недоделанности самого ЯП, когда в доке так прямо и пишут - это вот можно делать, но оно еще не продумано и не реализовано ни в каком виде

transform( a, a + 4, a, [](int x){ return x+1; } );

а теперь то же самое с каким-нибудь vector, например

a + 4

и даже размер контейнера само не умеет определять

работа на себя всяко приятнее

Это когда ты сам себе начальник? Мне было бы сложно, не люблю командовать. Но для многих - да, приятнее.

Так что в данный период жизни работа на дядю (дяди бывают очень хорошие) меня устраивает на 95%.

компилятор не бьет за это по рукам, вот что мешает.

мне не мешает. Наоборот помогает, ибо иногда _приходится_ отступить от правил. Это как с goto, которое в принципе не нужно. И тем не менее, иногда с ним лучше, чем без него. Код понятнее и яснее. Тоже самое с модулями.

Суть модульности ещё и в том, что тебе не нужно на каждый чих в инклюде пересобирать половину проекта.

это говорит о кривизне архитектуры by design. Архитектуры этих твоих *.hpp файлов. Например все либы можно распихать по шаблонам (типа как STL, boost), и тогда ты будешь в своём helloworld'е пересобирать ВСЁ. Ну да, есть такое, на это идут потому, что в рантайме есть некоторый профит от этого. Часто мизерный. Но есть и профит у программиста, ему писать быстрее, почти как в каком-нить php. Ну да, этому программисту приходится покупать комп мощный, но тебе-то как юзеру не всё-ли равно?

Из того что доводилось использовать:
php,
T-SQL (в той части которая не SQL),
c# (для server side)
jacl

когда на нем будут писать больше чем полтора анонимуса

к сожалению не будут, старая гвардия так и будет писать на плюсах (фигле, столько времени на освоение потрачено), а новички - хз

это не считая общей недоделанности самого ЯП

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

python, perl.

ибо иногда _приходится_ отступить от правил.

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

С++.

KISS как есть.

а теперь то же самое с каким-нибудь vector, например

transform( range(v), range(v), range(v), [](int x){ return x+1; } );

убрать два аргумента можно добавив свою реализацию transform через стандартный же (думаю очевидно), будет:

transform( range(v), [](int x){ return x+1; } );

range - шаблон, внутри два итератора и перегруженные операторы (писал выше), но опять же - это если есть идеологические причины не использовать итераторы напрямую

и даже размер контейнера само не умеет определять

ага, и по указателю в памяти тоже должно с помощью libastral нужный размер находить? ну и кто тебе сказал, что оно всегда должно со всем «контейнером» работать? я могу найти элемент внутри массива и изменить элементы до него, еще раз - это универсальная функция, не только для итераторов и не только для целых контейнеров

ну и ты уже забыл о чем шел разговор - я могу написать генератор чисел Фибоначчи, например, и отдать его на вход transform без всяких итераторов

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

я же говорю: шаблоны. Ну вот например, тебе хочется сделать массив int a[5], но что-бы индекс начинался с 1 и что-бы была проверка индекса 5≤i≤1. У тебя есть три пути:

1. выбрать ЯП, в котором это уже есть. Например паскал. Сам понимаешь, это не выход. Такой массив там есть, а других — нет.

2. сделать свою либу/модуль и хидер к ней.

3. сделать шаблонный класс. В этом случае, с одной стороны вся реализация у тебя будет внутри *.hpp, но с другой стороны ты избавишься от межмодульных накладных расходов, которые в этом случае ОЧЕНЬ большие. К примеру, даже самый глупый компилятор может выкинуть проверку в коде

for(int j = 1; j <= 5; j++)
  a[j] = 0;

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

свою реализацию transform

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

ага, и по указателю в памяти тоже должно с помощью libastral нужный размер находить?

шёл 21 век...

я могу найти элемент внутри массива и изменить элементы до него

только иммутабельность, только хардкор!

еще раз - это универсальная функция

а почему бы было не сделать более специализированные варианты? ну вот в той же scheme есть map, for-each, fold*.

упоролся? По твоему ЭТО

 ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++
 .>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.
 ------.--------.>+.>.

man KISS

ага, и по указателю в памяти тоже должно с помощью libastral нужный размер находить?

шёл 21 век...

да ещё в прошлом веке были в C++ SmartPointer'ы, которые умели находить что тебе угодно. В чём проблема-то? В том, что ты не знаешь C++?

а почему бы было не сделать более специализированные варианты? ну вот в той же scheme есть map, for-each, fold*.

что тебе мешает сделать всё тоже самое в C++? Хоть шаблонами, хоть другим модулем.

спросил у системы:

$ wtf kiss
KISS: keep it simple, stupid

Третье.