Embox v0.5.10

нет, там должно быть 13 везде, вот пример:

Public Module Program
	Public Sub Main(args() As string)
		Console.WriteLine( 13  ="13" )
		Console.WriteLine( 123 ="123")
		Console.WriteLine( 13  < 123 )
		Console.WriteLine("13" <"123")
	End Sub
End Module

True
True
True
False <------------------------ как тебе такое?

False <———————— как тебе такое?

Чем-то отличается от моего результата?

Это же сравнение строк, что нитак? Очевидно «3»>«2» при посимвольном сравнении строк?

Вот что не так:

a=A ==> true

b=B ==> true

a<b ==> true

A<B ==> … тут зрители ждут, что A<B, но у VBA совсем другое мнение!

Вот что не так: a=A b=B a<b … тут зрители ждут, что A<B, то у VBA совсем другое мнение!

Ничего не понял в твоем сообщении.

Если сравнивать числа, то 13 очевидно меньше 123.

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

ладно, начнем совсем с начала:

1. может ли в VBA быть так, что:

a=b ==> true
b=c ==> true
a=c ==> false

2. если да, то считаешь ли ты это нормальным?

Можно пример таких трех равенств?

Это вопрос не ко мне, а к тебе.

Нормальный язык не должен позволять 3 такие (не)равенства среди встроенных типов данных. И точно так же нормальный язык не должен позволять 4 (не)равенства про a,A,b,B среди встроенных типов данных.

A<B ==> … тут зрители ждут, что A<B, но у VBA совсем другое мнение!

Ненужно ожидать чудес там, где не учитывается результат вычисления функции typename(a1),typename(b1),typename(A2),typename(B2),

Btw, в VB регистр символов в именах переменных не принимается во внимание. Т.е. A и a указывают на одну и ту же переменную.

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

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

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

Но если эти 2 выражения разного типа признаны равными, то наоборот, результаты должны быть одинаковыми. Это требование к равенству выражений (и к одинаковости операций).

Т.е. можно было бы терпеть A gt B, но A>B терпеть нельзя (я продолжаю тот пример aAbB как если бы регистр букв имел значение)

Btw, в VB регистр символов в именах переменных не принимается во внимание. Т.е. A и a указывают на одну и ту же переменную.

Да, припоминаю. А так я уже почти 20 лет не писал на том, что стало VBA.

Если (не)равенство так сбоит в зависимости от typename,

Сбоит? LOL

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

? 1234<5678
True

? "Петя">"Вася"
True

? "567">"1234"
True

то это явный недостаток ума у того, кто делал эту систему типов.

Опа, внезапно начинается прием у шизотерапевтов, у которых нет даже BS in CS. Да что там, от силы у них степень *****френии в области CS :)

Для понимания идиотизма такого языка достаточно 2 первых курсов матмеха.

Но если эти 2 выражения разного типа признаны равными, то наоборот, результаты должны быть одинаковыми. Это требование к равенству выражений (и к одинаковости операций).

Программирование - это не чистая математика. Почитай для начала про перегрузку операторов.

Кроме того ты привел пример неравенства, а пример с равенством не привел.

Программирование - это не чистая математика. Почитай для начала про перегрузку операторов.

Спасибо, поржал. Про перегрузку на плюсах я читал 30 лет назад. И еще – у математиков как раз операторы перегружены в основном прилично.

Кроме того ты привел пример неравенства, а пример с равенством не привел.

Я и не должен был приводить пример равенства. Ты там рассказывал про свои 15 лет опыта, вот либо приведи такой пример из VBA, либо скажи, что наличие такого примера четко и однозначно бы считалось недоработкой автора.

Про перегрузку на плюсах я читал 30 лет назад.

Тогда зачем разводить весь этот цирк?

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

Я и не должен был приводить пример равенства.

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

Тупой индийский цирк разведен как раз в VBA.

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

Тупой индийский цирк разведен как раз в VBA.

VBA проектировался и разрабатывался true инженерами на территории НЕ Индии, а не как сейчас.

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

Да с чего бы VB стал строки с числами сравнивать как-то иначе? Кому надо, тот сначала конвертнет такую строку к числу.

Кто учился начиная с Turbo Pascal, наверно, не испытывает никакого недопонимания и у него нет никаких претензий к способу обработки строк в VB.

Про a=b b=c c<>a я именно спрашивал. И спрашиваю: если вдруг в VBA такое случится, ты по-прежнему скажешь «ну да, так и должно быть!111!11», или наконец поймешь, что язык делали тупые?

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

От типов выражений зависит, устал повторять.

VB делался для удобства, а не для твоих идеалов.

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

Однако были ли в то время конкуренты, кто умел бы «edit & continue» под отладчиком?

123="123" – это не удобство, а подлянка, которую, конечно, надо знать, когда пишешь на этом (недо)языке.

1. «edit & continue» не требует наличия таких подлянок.
2. Видимо у того, кто потребовал реализовать «edit & continue», головной мозг все же имелся.

С Bash еще сравни, в нем вообще сплошная засада.

Насчет «сплошной» не в курсе, я видимо только с одной знаком (т.е. с двумя, если включить операции сравнения). Список прочту с интересом.