And do you really think that this type of arguments will make much sense to the hordes of new users that Julia is expecting to attract from other languages and will want to have a simple answer to question: does my variable contains something or not?
That is just depressing. One of the best things about Julia so far has been that it seems to have the philosophy âdo the right thing, everything else be damnedâ and I sincerely hope it continues this way. If Julia fails as a language as a result of that, then come what may. At that point itâll be time for me to give up on society and become an island-dwelling hermit.
Lots of other languages in the past have followed the philosophy âattract users, advertise to ânon-programmersâ, the right thing be damnedâ and they are horrible. In particular Iâm thinking of COBOL, PHP and JavaScript. The first of these was unsuccessful, and the second is probably on its way out, the third will be the doom of us all. So 2/3âs of these examples perhaps give us a glimmer of hope.
On a less grandiose note, I also fail to see in what sense nothing
âisempty
â. Iâm not even convinced that most people would expect the result to be false
, even the aforementioned Mongol hordes.
I have moved these posts to a separate thread so that we can keep the original thread focused on the technical question of the behavior of isempty(nothing)
.
Please try to avoid âextortionâ arguments along these lines:
If you donât change this thing that I want changed, then I and the many other programmers like me will go away and not use your language and your project will fail.
If you have a reason why something is more intuitive, easier to use, or better in whatever way, then just make that argument and leave out the implied existential threat part.
Actually this is good a thing IMHO!
You could easily define isempty(x::Void) = true
if you want, but I would only use such helper functions if I had to port some Python for example and I feel a bit lazy (although a complete Julian refactor, would be better).
I find arguments that rely on hypothetical hordes to be unconvincing.
Rethorical technique (like above) is acceptable. It could also gain likes from people.
@joa-quim you could say that language is horrible but you have to choose proper language!
To be fair, I think there are very few people who think that COBOL or PHP are âgoodâ languages. The former is the butt of a lot of jokes. Ironically it also seems to me like there are very few people who âloveâ JavaScript (although perhaps that is only representative of people I have interacted with), the reason it is taking over the world seems to have far more to do with legacy than anything about the language itself.
I deliberately chose languages that I thought (perhaps incorrectly) were uncontroversially bad. That was the point I was trying to make: languages that start out by trying to appeal to newcomers with gimmickry wind up annoying those very same people after they have some experience actually using it. (There are at least some aspects of Python which are like this, but I did not include it because Python was far more successful at this sort of thing, indeed I think that Python is an excellent scripting language.)
I know I should probably try harder to avoid making derisive commentary about languages, as these sorts of things get started often and are seldom productive, but itâs really hard to say much of anything about how a programming language should be designed without referring to some precedent.
The problem with appealing to the âhordes of new usersâ and assuming anything about their preconceived notions is that, aside from being a weak rhetorical argument, youâre almost definitely wrong anyway!
By definition, if you are using Julia and reading messages on this board today, Feb. 25, 2018, you are an early adopter. Your motivations will be different than the âhordesâ. Your past experiences, expectations, and therefore assumptions will be colored by the fact that you are an early adopter. So, to paraphrase an engineering manager at a former job: letâs try, whenever possible, to write correct code.
Iâm reminded of a common refrain I first heard in reference to Git, but have also heard in reference to Haskell, Erlang, functional programming in general, and a bunch of other âout thereâ technologies: itâs easier to learn if you donât know anything else first. I donât know about the rest, but for Git Iâve certainly found that to be true. Iâve trained first-time programmers who had no problem with Git, and I know grey-beard hackers that still insist on using Subversion.
Letâs leave the existential angst for arguments over issetthatdoesntcontainself(nothing)
.
Itâs really all relative: compared to the alternatives in 1959 (assembly language or some simpler mostly machine specific languages, such as FLOW-MATIC, which COBOL was based on), COBOL was a great advance, and 30 years ago, according to certain reports, was the most used language in the world. (It is estimated that 80% of the worldâs daily business transactions still rely on COBOL) (see BIG777: Situs Judi Slot Gacor Terpercaya & Slot88 Gampang Jackpot Hari Ini)
I would say that my Miata is uncontroversially better than a Model-T Ford, however, at the time it came out, the Model-T was considered a great car.