> Why should this be changed? Is it broken? Is it something that 1 second on google can’t answer?
Pretty sure every year there's thousands of unnecessary search requests for this nonsense.
Programming languages are tools. Make it as easy and straightforward as possible so that its users can build whatever it is they were building with the least amount of friction.
> There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel
Funny because PHP — particularly theearlier versions — isn't exactly considered an example of good language design (though it has vastly improved recently).
> but you google it once in your life and then you ‘forget’ about it.
Negative. I had forgotten what it meant. All I remembered was that I've seen it years ago and was annoyed back then.
> And if you can’t remember the meaning of something like that, I hardly doubt you’d be a decent programmer anyway.
That's just, wrong on so many levels. Anyway, I'm just happy they didn't say anything like "people who screw up colons shouldn't be coding"
To me, it feels like adding a booby trap in one of emergency rooms in the hospital.
When nurses complain about the injuries and the inconvenience, you berate them because "if they can't remember that in room 4 there is a booby trap, are they really intelligent enough to be nurses?"
This exact argument was made about pilots. If they can't figure out <counter-intuitive nonsense design>, then they shouldn't be pilots!
For a recent example, the MCAS design is nonsense, yet people were blaming the pilots, stating something along the lines of: "On page 837 paragraph 7, there's half a sentence that explains how to resolve the issue."
Forgetting to mention that the cause of the issue was purposefully omitted, and that the issue of unexpected trim change typically has a familiar and resolvable cause, not one that physically overpowers pilots... repeatedly. With delays. With no warning signal.
Even other pilots were blaming the dead pilots for making mistakes that were not humanly possible to avoid or recover from.
The old Frank Borman quote is: "A superior pilot uses his superior judgment to avoid situations which require the use of his superior skill."
Maybe we need to add: "A superior aircraft designer uses their superior design skills to avoid situations which require a superior pilot".
There really are apparently "trivial" things in even vaguely modern (like maybe 50+ years old) aircraft that were not like that in 1940s or sometimes 1950s planes because even though we know they killed people the attitude was "You should just know about that". No, fix the plane.
Certainly for programming languages we need to be clear that bad error messages aren't a lack of knowledge by the programmer, they reflect poorly on the quality of the software.
But this applies generally across the design of everyday things. That push door with the word "PULL" written backwards? That's a bad design. Yes, I understand, I am reading a sign meant for people on the other side of the door, but you should have designed the door differently.
Or a thing that periodically annoys me: USB A plugs have the USB trident logo on them. The USB compliance rules say to put the logo on the "top" of the plug. So e.g. if you plug six USB A things into a typical laptop, the logo faces up on every port, the ports are all oriented the same way. So it ought to be very easy to insert USB A plugs when you can see what you're doing. Not perfect, but hey - except even some fairly decent brands decide their brand logo is more important than compliance, so e.g. this XBox controller plugged into a Windows laptop is "upside down" because they just couldn't bear to put the trident logo where the compliance rules said it needs to be...
Why stop at bad design? The cause for that design decision had (as often) monetary/managment reasons.
So the bad design decision resulted from a bad business decision, which was the result of the whole incentive structure within the company, which was the result of the way that corporation operates (has to operate?) within a capitalist environment.
On another layer the regulators did not prevent the MCAS because they themselves have been influenced by economic incentives, lobbying and lack of expertise. In short: capitalism again.
If we wanna live in a capitalist society that is driven by such incentives, we need to be aware that the huge resources and big incentives for corps to take shortcuts and prevent effective regulatory overssight need a powerful counterplayer that is capable of keeping these entities in check.
How we go about that is a different thing, but anybody labouring under the illusion that a next MCAS could be prevented by market forces alone should go see a doctor.
> The cause for that design decision had (as often) monetary/managment reasons.
In the particular case of MCAS that's true, but so often it's simply thoughtless.
Management aren't often given a menu of options with "Really terrible idea that might be profitable" picked from the list. People down in the trenches don't know why you should do X rather than Y and so 50-50 chance you get either, despite the differences. If you told them, "Oh, don't do Y if you can do X, here's why" they'd make better choices and we'd only be talking about cases where management actually said "Yeah, do the terrible idea, we think that would be profitable".
That's a paper for WG21, the C++ Committee to read, but don't worry about what it means, look at how it was rendered. A big section from pages 8 and 9 is "highlighted" by changing the text background to angry red. In the process for many people this text is rendered unreadable due to contrast problems.
Nobody in "The Direction Group" is a rogue artist, here to confront us with black-on-red text as a metaphor for why it's wrong to worry about programming language safety or whatever -- just somebody clicked red in their word processor without really thinking about it and likely with no understanding of why it might be a bad idea.
> That's just, wrong on so many levels. Anyway, I'm just happy they didn't say anything like "people who screw up colons shouldn't be coding"
A lot of those arguments read like they have a lack of empathy and desire to make things easier for new programmers who want to learn or use the language. To me, it comes across as if coming from a position of arrogance, especially the latter claim - a perspective that I've sadly have encountered often, with many people unapologetically being happy about their solutions or the status quo being being unapproachable or needlessly complex - be in regards to system design, code structure, or even how entire libraries (or languages) work.
Then again, even people like Richard Stallman and Linus Torvalds have been known to be difficult in certain regards. I'm not sure whether our industry seems to attract people who have strong feelings about certain things, or whether those beliefs are simply more apparent. Either way, you'll have to deal with that, either because of technologies that you need to use and don't have control over, or because of having to work on certain projects together with developers like that.
Best you can do is probably be as nice as you can towards others yourself.
Read through old-ish posts on their maintainer mailing lists. There’s so much snobbery, elitism, and straight-out hostility to anyone from the outside, it reads like 8chan.
This has changed by now, but the PHP maintainer community before version 7 was a circle jerk of hyper anal trolls.
This remind me a discussion about making Wordpress natively compatible with Sqlite. Somebody put on the the table that Sqlite is using the rule of St. Benedict (adapted I would say) as they code of conduct and that should be a no-go for such development.
I still think the debate over renaming that token had the wrong premise. It's not like “Expected T_STRING” is helpful either (yes that's real, no it's not a string literal). Token names are never user-friendly and shouldn't be user-facing, they should be an implementation detail.
By who's authority should the word "who's" be spelled "whose" and not "who's"?
In all seriousness, it's interesting to see how the live language is diverging from the rules. The dual ending "-ayim" is supposed to be used with the singular stem: nekuda(-t) - giving nekudatayim "two dots", and likewise shnatayim "two years", dakatayim "two minutes", etc. But in practice, speakers classify dual as plural and use the form with both plural and dual endings: nekudotayim, dakotayim
To be fair, Hebrew does have an official regulatory institute in the (ironically named) Academy of the Hebrew language. But indeed 100% of modern Hebrew speakers will say "nekudotayim" and not "nekudatayim" and maybe eventually the academy will catch up with that and make it official (just like they somewhat recently did with socks :)).
the Israeli standard way of romanizing hebrew looks weird to any person whose first language is english.
take the Israel city of Petach Tikvah. Assuming you know about the gutural h in hebrew, you know how to pronounce it correctly via that spelling. However, that's not the official transliteration. The official one is Petah Tiqwa. And unless you know that the w should be pronounced like a v, most israelis (perhaps not those of yemenite extraction) will look at you strangely.
why transliterated weirdly? my understanding is that its meant to be able to go 1:1 programmatically back and forth between hebrew and english, so you end up with things that look weird to the english trained eye.
Like 20 years ago I sent the PHP folks a patch to make yacc generate errors in verbose mode or something, which causes the error message explain exactly what you need to do to fix this. It didn't get applied.
(Someone should also look at my PR for golang.org/x/net/trace from like 5 years ago.)
i think hebrew is fairly phonologically simple, isn't it
on glancing at the overview, the only thing that looks remotely challenging is that [χ] (כ or ח) contrasts with [ʁ] (ר)
even the vowel system is roughly the same five-vowel system used by languages like spanish (and nearly japanese), and both consonantal gemination and phonemic vowel length have been dropped in modern hebrew
we're not talking about something like keresan here
Do you realize how ridiculous you sound? 99% of people aren't going to know how to pronounce this, and even ones that think they do probably get it wrong.
99% of people don't know how to calculate the pressure loss due to turbulent flow through a long pipe either but they can look it up
the nice thing about languages with a relatively small inventory of phonemes is that getting pronunciations wrong is kind of hard
at worst you just sound like you have a weird accent
it's not like french or portuguese or chinese or ...
probably if i sound ridiculous to you it's because you're so out of your depth in the conversation you don't even know what knowledge you're missing, just like when i corrected you in https://news.ycombinator.com/item?id=33753071
you would probably find it more to your advantage to try to learn the relevant things you don't know than to attempt to ridicule other people for knowing them
i refuted the argument you made first, though perhaps you lack the background knowledge to recognize that, and i didn't 'dig into someones comment history', i just recognized your name because it has only been a week since you got in my face in an aggressively ignorant way about linguistics stuff, and here you are doing the same thing again
i would like you to stop
ridiculing people for knowing things you don't is a terrible thing to do to yourself, and it also degrades the quality of the conversation for others
> you lack the background knowledge to recognize that
you want someone to stop, but yet you continually insult them, and crawl through their previous comments in order to avoid actually countering points made. I would like you to stop.
none of 'you continually insult them', '[you] crawl through their previous comments', nor '[you] avoid ... countering points made' are true
the second and third could have been honest mistakes, but i have already corrected you about them above, so they are no longer honest mistakes
i haven't insulted you at all
i just think your behavior is highly suboptimal and i would like it to be better
i am not going to stop doing any of the things you have asked me to stop doing because i would have to start doing them first in order to be able to stop
you are lying about me and i would like you to stop that too
I remember getting that error in the past, and at the time googling for that token gave few results, so it was a slightly bigger deal than you would think.
99% of the time the cause was: you are on PHP 5.2, but we're trying to use PHP 5.3 late static binding ( `static::someMethod()` ).
As a Hebrew speaker, I have to say that even though one should stick to English in code, paamayim nekudotayim was probably used because it rhymes; it has rhythm; it sounds like nothing you would say in ordinary circumstances.
There are a lot of words in French or Japanese that rhyme with keywords or English variable names in the projects I am working on. But I don't think my PO would be very happy if someone called him at 3 'o clock asking what the hell that line in the logs means.
As far as I know, the "on fire" joke originated in purely professional environments of the 50s or so, and got added to Linux in the early days when nobody but the most hardcore nerds used it.
An obscure in-joke makes sense when the system is used by the dozen people that will get it.
It quickly starts being annoying when you go mainstream.
Because Unix jokes don't make something that should be easy needlessly hard. If a double-colon is missing, then the error message should state that, in the language that 99.9% of the language is written in.
...then I would indeed have to google it, unless I just so happened to know the japanese words for "wave bracket" and "round bracket"
My point is: a good message about an error as simple as an unexpected or missing syntactical element can convey all the information I need to fix the problem, without requiring me to invoke a supremely powerful search engine, indexing the largest repository of collective human knowledge in existence, to make sense of it.
I don't even use PHP regularly anymore, and never did encounter that message even when I did --- probably because my use of PHP predated all the OOP stuff --- but I still remember that word after reading articles about this precisely because it's so memorable. It's sad to see that they removed it in an attempt to effectively dumb down the language even more to cater to those not willing to use their brains and learn a bit about its (IMHO interesting) history. The other example of memorable words that I associate with a programming language are car and cdr.
If you want to learn the history, go read "the history of PHP". There's tons opf it, none of it relevant to people who want to program modern PHP.
If you want to actually use PHP, or any other language, and the interpreter/compiler throws up errors that _cannot be understood_ by "using your brain" then that is both a bad design decision that should have been changed way back when, _and_ is a current bug in your interpreter/compiler that you need to fix.
> complaining about how everything should be "easy"
Not the worst thing to complain about.
Things that ought to be easy should be easy, so that time can be spent on solving hard problems.
T_PAAMAYIM_NEKUDOTAYIM is an example of something easy made deliberately hard. Thousands of people had to search for it (it adds up in the aggregate).
And not only that, now there's mundane debates around whether or not it was a bad idea (such as right here, but also in the linked article). Further waste of time.
It’s not that hard, right. Nothing is really hard when an explanation is one search keyword away. But even a little bit becomes an issue when you fed up. This has nothing to do with skills and intelligence, the argument is emotional. If you don’t get fed up bit by bit in our profession or you work at the place where you have plenty of time to digest anything irrelevant, lucky you.
How is writing things in random languages "intellectual" ?
If I replace a random λέξη[0] in my comments with its equivalent in another language for no reason, is someone being "anti-intellectual" for thinking that's silly?
> It's sad to see that they removed it in an attempt to effectively dumb down the language even more to cater to those not willing to use their brains and learn a bit about its (IMHO interesting) history.
As an alternative explanation, perhaps people don't want to be using Google to look up an obscure error message when they're in the middle of writing code, when the error message could be better and the history of the programming language is irrelevant to the problem at hand?
Here's the deal. Haskell has “Functor” (mappable), “Monoid” (aggregate/summary), “Foldable” (summarizable), “Monad” (context/commandlike). This language comes from a lot of early adopters being math nerds of a sort. It is a barrier to entry, and everyone understands that.
PHP’s situation is worse because, you know what's true about PHP developers? They are often just learning programming. It is an entry-level language, something you can throw into the HTML you already have to make some magic happen. Yes it can be so much more, but it ALSO is a lot of peoples' first look at programming. When you chose to learn Haskell you knew you were jumping in the deep end. The sitch with PHP is grown adults nearly drowning in a kiddie pool.
Look, when Haskell condescends to me, “Your rigid skolem type variables are bound by the type signature for fizzBuzz!” I know as a seasoned programmer that I am experiencing my own masochism and that I should probably Google away and that I may end up having to read a PDF by Dr. Craig T. Skolem to find out why he has a species of type variables named after him. But if you are just starting out? It just makes you feel like you will never be able to do this and why did you even try.
So keep T_PAAMAYIM_NEKUDOTAYIM in the error message, feel free, I don't care. But IF it is there, please include in your English error messages in some brackets, “(that’s Hebrew for ‘double colon’, it helps for searching errors online)” or something like that. If you find that line in the error message smug/condescending, then T_PAAMAYIM_NEKUDOTAYIM is all the more smug, because it has the same implications but hidden behind an extra smug superiority, “you don't know the history of this language, do you?!” Or, on the flip side, as long as the error message explains what went wrong and hints how to fix it, feel free to inject a mini Hebrew lesson into my day, sure.
To be honest I don't know what the fuck your (parenthetical) terms were. You just have to learn those things under some name, and even if you know what a functor is in maths it won't tell you how to write Haskell. There's no magic word that will tell you exactly what something is, unless you already know the exact concept by a different name. You can try to make the names mnemonic, but they can't be a whole explanation.
I remember running into this error back in the day and wondering why it was named in such a manner I had to search it up rather than getting an explanation on what actually went wrong. These people wanted to make things hard for no good reason.
Lisp uses these names decades before Clojure, see for example the Lisp Machine Manual from 1979 which documents first, second, ..., seventh, rest1, rest2, ...
The difference is that Clojure does not have cons cells with CAR and CDR like in Lisp. The special dot notation (a . b) does not exist in Clojure. Clojure has something like cons, but they don't work like in Lisp.
In Lisp the cons cells are the building blocks for ALL list like data structures: lists, circular lists, cons trees, etc. CAR and CDR can have arbitrary contents: (1 . 2) describes a valid cons cell. In Lisp the function CONS accepts two arbitrary objects and returns a cons cell.
Where in Clojure the dot notation for cons cells does not exist and where the function cons is a function which accepts an object as first argument and a seq as second argument. It returns a seq. No such function exists in Lisp.
Thus CAR and CDR would not make no sense for Clojure, because it does not support CONS cells with CAR and CDR. It uses seqs (etc.) instead.
In Lisp there is a style convention that the names FIRST, SECOND, ... and REST should be used in code which uses conses as lists. When conses are used to build trees (which are not lists), the operators CAR, CDR and related are preferred.
I don't get it. What was wrong with the following abbreviations: "Contents of the Address Register" (CAR), "Contents of the Decrement Register" (CDR)? IMO they're self-describing.
It also allow you to use all the premutations of Address and Decrement registers: C[A|D]+R. How do you do this with "first" and "rest"? ;)
And in the theme of the post, I kind of miss those old terms that I remember fondly from learning Scheme a long time ago. Using them felt like incarnating some ancient magic.
That said, the terms "first" and "rest" are superior, and one of the things I love about Clojure is that it never makes anything obscure.
Pretty sure every year there's thousands of unnecessary search requests for this nonsense.
Programming languages are tools. Make it as easy and straightforward as possible so that its users can build whatever it is they were building with the least amount of friction.
> There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel
Funny because PHP — particularly theearlier versions — isn't exactly considered an example of good language design (though it has vastly improved recently).
> but you google it once in your life and then you ‘forget’ about it.
Negative. I had forgotten what it meant. All I remembered was that I've seen it years ago and was annoyed back then.
> And if you can’t remember the meaning of something like that, I hardly doubt you’d be a decent programmer anyway.
That's just, wrong on so many levels. Anyway, I'm just happy they didn't say anything like "people who screw up colons shouldn't be coding"