Command Line vs. GUI on Linux
-
@pie_flavor the thing is, I believe that having verbs and objects seems like good design and seems to make things easier, but I think it's the opposite. Also because you have to subscribe to the designer's vision of the "world". Natural languages are interpreted by humans that will still understand you if you say that you want to "cook bread" instead of "baking" it. I beIieve it's actually better to have "meaningless" terms (that you can expand or at least pronounce, like grep, sed, whatever) because they become more memorable.
-
@admiral_p speak for yourself. Given a desired action you may still need to look up what command you use to achieve it, but at least the inverse isn't true when you have descriptive names. I like my methods named
foo.GetBarData()and notfoo.Gbdat().
-
@pie_flavor oh come on, names like
strstr,strtoldstrcoll,strspn, andstrpbrkare very memorable.
-
@pie_flavor those are easily confused. Grep, echo, cat, wget, touch etc. aren't.
-
@admiral_p "touch" is your example? "cat"?
You are so detached from normal human thought, I don't think it's worthwhile talking to you about usability issues.
-
@admiral_p Right. And you're telling me that
grepmakes more sense thanSelect-String,echothanWrite-Output,catthanGet-Content,wgetthanInvoke-WebRequest,touchthanNew-Item?Meanwhile, if you want to use your weird abbreviations, then set up aliases for them in your profile script.
echo,cat, andwgetare actually already built in aliases.
-
@blakeyrat maybe I am. Maybe I am. You see, I'm a language teacher by trade. In my experience, people don't easily learn words or expressions when they "make sense", it's easier when they don't make much sense and/or there is something weird, funny or quirky about them, because when they make sense, they don't always really do, and when they're surprising (yet easy to remember) they tend to stick. I have students who can successfully use words, expressions and short phrases in context when they have funny sound, when it reminds them of something else, etc. and may have difficulty even when they have an internal consistency, because their native language has another logic.
-
@blakeyrat I'll also add that CS is very Anglo-centric (justifiably so, mind you). If you don't speak English a "while" loop is (or might be) just a "while" loop, at least at first. Programmers who might have the need, when speaking in (broken) English, to use "while" in a sentence, may not be able to recall the word even if they use it (or have studied it) a lot. ("Oh, of course, while, like the while loop!").
There is a reason why Excel localises function names, after all.
-
@admiral_p said in Command Line vs. GUI on Linux:
There is a reason why Excel localises function names, after all.
We already established that the person who decided that deserves to be stoned
-
@luhmann said in Command Line vs. GUI on Linux:
We already established that the person who decided that
deserves to bewas stoned
-
@luhmann said in Command Line vs. GUI on Linux:
@admiral_p said in Command Line vs. GUI on Linux:
There is a reason why Excel localises function names, after all.
We already established that the person who decided that deserves to be stoned
Translating the function names would’ve helped a lot in getting people to adopt it, though. I doubt spreadsheets would have taken off the way they have if almost everybody outside of English-speaking countries had to write their functions in a language they don’t know, so that
IF,TRUE,SUBSTITUTE, etc. are all just semi-random bunches of letters to them.
-
@gurth ...and then someone asks me do debug their Excel sheet, and their Excel is in language I don’t speak, and even if I speak it, I have no idea how exactly that shit is translated.
-
@wft that's a very minor setback. It's not as if it is impossible to work around this. (Like, at all).
-
@gurth said in Command Line vs. GUI on Linux:
Translating the function names would’ve helped a lot in getting people to adopt it, though.
Or maybe it didn't. But since it already happened, we can't test the alternative, so we'll never know!
@admiral_p said in Command Line vs. GUI on Linux:
@wft that's a very minor setback.
But googling for some problem and only getting solutions in other languages is a major setback. Especially since Excel translators were very liberal with keeping the original meaning.
-
@Gąska when Excel became a thing the Internet was some futuristic sci-fi thingy. It still makes sense as a choice anyway. That people must learn English is sort of fucked up. Of course, it's inevitable except when it isn't. It isn't in Excel. That's good.
-
@gąska by the way, I'd expect the translation of each function to be available in the official documentation. Use the documentation. And anyway, now you get the plight of the typical non-Anglophone. Imagine my fellow Italians searching for a solution on Google and only finding solutions in English. Now stop imagining, that's what actually happens.
Bonus level: common mispronunciations
Get = Jet
While = Wheel
Open Source = Open Soor-ss
Write = V-right
Main = Mine
The funniest: Yahoo = Yah-ho. I had the guy repeat the word like five times. I really, really couldn't understand what he was talking about. Then it's me who's the fancy guy who's a pronunciation Nazi.
-
@admiral_p said in Command Line vs. GUI on Linux:
@Gąska when Excel became a thing the Internet was some futuristic sci-fi thingy.
In Eastern Europe, Excel has become a thing roughly at the same time as everything else related to computers, all at once (~1993). It's hard for me to say for sure because schools skewed those stats somewhat, but I wouldn't be surprised if many people had internet before they had MS Office. But I'm digressing.
If your design decisions are only good in 1985, your software should be left in 1985.
It still makes sense as a choice anyway.
No one doubts it. But does it make more sense than alternatives?
That people must learn English is sort of fucked up.
Maybe, but that's the world we live in. And I don't just mean IT - a big part of every modern society has been infested with English words, and with that, American culture. Just like Latin in middle ages, Italian in 15-16th century, and French in 18-19th.
That said, I doubt the rate at which you learn programming languages (and Excel formulas is a programming language, in some sense) is affected much by the knowledge of the human language a given programming language is based on. The grammar doesn't apply almost at all, and vocabulary both limited enough that it's not a problem memorizing most important bits even if you didn't know the words before, and different enough from source language that knowing it doesn't let you skip learning vocabulary.
Of course, it's inevitable except when it isn't. It isn't in Excel. That's good.
You skipped the part where you show why it's good. Yes, it's kinda nice that the made up language that Excel formulas are written in bears some similarities to the user's native language. But it creates major problems for people who switch from one dialect of Excel formulas to another, because all the words are suddenly something else, and because of how natural languages work, you can't just use the standard dictionary to figure out the translations. Not to mention other ways locale fucks up formulas (separators, date and time formats...). Is it all outweighed by the benefits of having the formula language based on user's language?
-
@admiral_p said in Command Line vs. GUI on Linux:
@gąska by the way, I'd expect the translation of each function to be available in the official documentation. Use the documentation.
There is. Kinda, sorta. Incomplete, hard to find, and not sure since when, but there is.
And anyway, now you get the plight of the typical non-Anglophone. Imagine my fellow Italians searching for a solution on Google and only finding solutions in English.
Solution as in the code snippet they need to copy, or solution as in the entire article? Because the first isn't a problem for anyone, and the latter is better than no solution at all (and with translated formulas, even people who know English well and have no problem reading the article, are left with no solution at all).
Now stop imagining, that's what actually happens.
I know. FYI: I'm Polish.
Bonus level: common mispronunciations
Get = Jet
While = Wheel
Open Source = Open Soor-ss
Write = V-right
Main = Mine
The funniest: Yahoo = Yah-ho.Okay, but how does mispronouncing prevent them from doing anything with the computers, whether it's use programs or google up answers?
-
@gąska said in Command Line vs. GUI on Linux:
@admiral_p said in Command Line vs. GUI on Linux:
@Gąska when Excel became a thing the Internet was some futuristic sci-fi thingy.
In Eastern Europe, Excel has become a thing roughly at the same time as everything else related to computers, all at once (~1993). It's hard for me to say for sure because schools skewed those stats somewhat, but I wouldn't be surprised if many people had internet before they had MS Office. But I'm digressing.
If your design decisions are only good in 1985, your software should be left in 1985.
Is "Googleability" a key design criterion? I suppose it can be, yes, but Excel predates Google.
It still makes sense as a choice anyway.
No one doubts it. But does it make more sense than alternatives?
Who uses Excel? Office workers, accountants, secretaries who may not need to speak English at all.
That people must learn English is sort of fucked up.
Maybe, but that's the world we live in. And I don't just mean IT - a big part of every modern society has been infested with English words, and with that, American culture. Just like Latin in middle ages, Italian in 15-16th century, and French in 18-19th.
Yeah. And those were shit ages to live in, where most people couldn't read or write anyway.
That said, I doubt the rate at which you learn programming languages (and Excel formulas is a programming language, in some sense) is affected much by the knowledge of the human language a given programming language is based on. The grammar doesn't apply almost at all, and vocabulary both limited enough that it's not a problem memorizing most important bits even if you didn't know the words before, and different enough from source language that knowing it doesn't let you skip learning vocabulary.
Which is why I argue that languages that try to make sense may not make sense anyway, and at least with cute names like touch and cat or with easy to remember stuff like grep and yum/apt/pacman there is a chance that you make your own associations.
Of course, it's inevitable except when it isn't. It isn't in Excel. That's good.
You skipped the part where you show why it's good. Yes, it's kinda nice that the made up language that Excel formulas are written in bears some similarities to the user's native language. But it creates major problems for people who switch from one dialect of Excel formulas to another, because all the words are suddenly something else, and because of how natural languages work, you can't just use the standard dictionary to figure out the translations. Not to mention other ways locale fucks up formulas (separators, date and time formats...). Is it all outweighed by the benefits of having the formula language based on user's language?
You don't have to use the dictionary for the function names, why are you using a dictionary?
-
This post is deleted!
-
@gąska said in Command Line vs. GUI on Linux:
@admiral_p said in Command Line vs. GUI on Linux:
@gąska by the way, I'd expect the translation of each function to be available in the official documentation. Use the documentation.
There is. Kinda, sorta. Incomplete, hard to find, and not sure since when, but there is.
So there you go. If anything complain to Microsoft about their documentation, not their Excel language.
And anyway, now you get the plight of the typical non-Anglophone. Imagine my fellow Italians searching for a solution on Google and only finding solutions in English.
Solution as in the code snippet they need to copy, or solution as in the entire article? Because the first isn't a problem for anyone, and the latter is better than no solution at all (and with translated formulas, even people who know English well and have no problem reading the article, are left with no solution at all).
Is copypasting code snippets when you don't truly get what the article is about sane, safe and secure anywhere in the world?
Now stop imagining, that's what actually happens.
I know. FYI: I'm Polish.
You have the privilege of having been able to learn English and being at ease speaking English. Meanwhile, a maybe more talented coder than you might be hindered by an inability to comprehend English easily so that he has more trouble evolving.or keeping up to speed. This actually happens in real life by the way.
Bonus level: common mispronunciations
Get = Jet
While = Wheel
Open Source = Open Soor-ss
Write = V-right
Main = Mine
The funniest: Yahoo = Yah-ho.Okay, but how does mispronouncing prevent them from doing anything with the computers, whether it's use programs or google up answers?
That's why it's a bonus level. It's funny.
-
@admiral_p said in Command Line vs. GUI on Linux:
@gąska said in Command Line vs. GUI on Linux:
@admiral_p said in Command Line vs. GUI on Linux:
@Gąska when Excel became a thing the Internet was some futuristic sci-fi thingy.
In Eastern Europe, Excel has become a thing roughly at the same time as everything else related to computers, all at once (~1993). It's hard for me to say for sure because schools skewed those stats somewhat, but I wouldn't be surprised if many people had internet before they had MS Office. But I'm digressing.
If your design decisions are only good in 1985, your software should be left in 1985.
Is "Googleability" a key design criterion? I suppose it can be, yes, but Excel predates Google.
Excel 2000 doesn't predate Google, and neither does any later version.
It still makes sense as a choice anyway.
No one doubts it. But does it make more sense than alternatives?
Who uses Excel? Office workers, accountants, secretaries who may not need to speak English at all.
I don't know about Italy, but in Poland, half-decent English is a prerequisite for all those positions. But that aside - I've just spent entire post explaining why speaking English is irrelevant even if formulas are in "English". How about you read it?
That people must learn English is sort of fucked up.
Maybe, but that's the world we live in. And I don't just mean IT - a big part of every modern society has been infested with English words, and with that, American culture. Just like Latin in middle ages, Italian in 15-16th century, and French in 18-19th.
Yeah. And those were shit ages to live in, where most people couldn't read or write anyway.
But that has nothing to do with Latin, Italian, French or English. In fact, it has nothing to do with anything at all in this topic.
That said, I doubt the rate at which you learn programming languages (and Excel formulas is a programming language, in some sense) is affected much by the knowledge of the human language a given programming language is based on. The grammar doesn't apply almost at all, and vocabulary both limited enough that it's not a problem memorizing most important bits even if you didn't know the words before, and different enough from source language that knowing it doesn't let you skip learning vocabulary.
Which is why I argue that languages that try to make sense may not make sense anyway, and at least with cute names like touch and cat or with easy to remember stuff like grep and yum/apt/pacman there is a chance that you make your own associations.
Are we talking about Excel, or are we talking about PowerShell now? Because I don't want to mix these two topics, because points raised in one don't make sense in the context of the other.
Of course, it's inevitable except when it isn't. It isn't in Excel. That's good.
You skipped the part where you show why it's good. Yes, it's kinda nice that the made up language that Excel formulas are written in bears some similarities to the user's native language. But it creates major problems for people who switch from one dialect of Excel formulas to another, because all the words are suddenly something else, and because of how natural languages work, you can't just use the standard dictionary to figure out the translations. Not to mention other ways locale fucks up formulas (separators, date and time formats...). Is it all outweighed by the benefits of having the formula language based on user's language?
You don't have to use the dictionary for the function names, why are you using a dictionary?
Your question doesn't make sense to me. Are you saying that there is never need to know what is a given Excel function called in another language version of Excel? When you say "use the dictionary", do you mean "translate in general, not necessarily with dictionary", or do you mean "use the dictionary to translate as opposed to using other ways to translate"?
-
@admiral_p said in Command Line vs. GUI on Linux:
@gąska said in Command Line vs. GUI on Linux:
@admiral_p said in Command Line vs. GUI on Linux:
@gąska by the way, I'd expect the translation of each function to be available in the official documentation. Use the documentation.
There is. Kinda, sorta. Incomplete, hard to find, and not sure since when, but there is.
So there you go. If anything complain to Microsoft about their documentation, not their Excel language.
If documenting stuff is a valid fix for usability problem in your book, then it shouldn't matter to you what language Excel function names are derived from as long as they're all documented in local language. And they are all documented in local language anyway. Unlike translations, which are only 98% documented. Someone mentioned SUBSTITUTE function. It's missing in the MS official terminology translator - had to find it on some random blog.
And anyway, now you get the plight of the typical non-Anglophone. Imagine my fellow Italians searching for a solution on Google and only finding solutions in English.
Solution as in the code snippet they need to copy, or solution as in the entire article? Because the first isn't a problem for anyone, and the latter is better than no solution at all (and with translated formulas, even people who know English well and have no problem reading the article, are left with no solution at all).
Is copypasting code snippets when you don't truly get what the article is about sane, safe and secure anywhere in the world?
Another problem with Excel: copypasting what should be a pure mathematical formula can introduce security vulnerabilities.
But that aside - I can understand everything about the formula down to individual bits that get switched in Excel internal memory when executing it, but still be unable to apply the formula because I don't know my local counterparts of the function names I'm seeing. Whereas if all languages used single function names set, whether it's English or Swedish, there wouldn't be this problem - without any downsides.
Now stop imagining, that's what actually happens.
I know. FYI: I'm Polish.
You have the privilege of having been able to learn English and being at ease speaking English.
But my brother didn't. He's 26 now and his English is roughly at grade school level, but it never prevented him from playing English games or using English software. He sees the letters, he joins them together, he memorizes the sequences, and that's all he needs for reading item stats or writing Excel formulas. And neither task would get significantly easier if they were in Polish.
Meanwhile, a maybe more talented coder than you might be hindered by an inability to comprehend English easily so that he has more trouble evolving. or keeping up to speed. This actually happens in real life by the way.
But not because he has trouble memorizing keywords in his language of choice. Yes, it sucks not to be able to read 90% of teaching material available in your discipline, but that has nothing to do with the topic.
-
@gąska OK, let's tidy the thread up a bit. My opinion is that having keywords which are meaningful in English may be useful only to English speakers, and that funny names, acronyms, etc. for basic stuff could be more effective because a developer/power user, who is already well inclined to talking to a computer, may remember stuff better if you put some "hacker humour" in it. We're talking about a CLI here. (We all agree that the CLI is a h4X0r interface, right?).
A library, a complex computer language needs some internal consistency, then having meaningful function and variable names is a plus. No to strcat, strncat, strcpy, strncpy etc. (because they're easily confused). I'm for camel casing by the way. It's cleaner, it better separates each word, etc. It's unfortunate that you have to deal with English but that's the way it is (for an English speaker, it's natural that stuff has the name it has, the others just learn the word without necessarily understanding it. The game is "LOADING", not loading. It's one more step and I think it leads to a potentially worse understanding of how a computer works. Remember that the language you speak shapes your mind).
Excel is meant to be used by people who may hate computers. And they want the computer to behave as little as a computer as possible. They have different requirements. They don't want to be developers, they use a computer because they have to or because it's convenient for their job, but have no interest in any design considerations. If you make the language as familiar to them as possible it's better. Who cares about the (foreign? Why is he foreign anyway?) support worker who you hopefully never have to call?
-
And yes, I also believe that having English as a lingua franca gives an unfair advantage to English speakers. Latin at least was a dead language and everybody was in the same boat. A lingua franca is inevitable but it's still fucked up. I bet that if you compare English speaking countries (even as a popular second language, eg. the Netherlands, Scandinavia, etc.) with those that aren't, the former are better developed in the IT sector than the latter.
-
@admiral_p said in Command Line vs. GUI on Linux:
A lingua franca is inevitable but it's still fucked up.
You could use French as a lingua franca…
-
@admiral_p said in Command Line vs. GUI on Linux:
@gąska OK, let's tidy the thread up a bit. My opinion is that having keywords which are meaningful in English may be useful only to English speakers, and that funny names, acronyms, etc. for basic stuff could be more effective because a developer/power user, who is already well inclined to talking to a computer, may remember stuff better if you put some "hacker humour" in it. We're talking about a CLI here.
My opinion is that professional tools (and CLI tools are professional tools - if you make CLI tools for basic home users, I hate your guts), and there's nothing wrong with expecting IT professionals to know basic English, just like doctors are expected to know basic Latin and physicists are expected to know SI units even if they're from USA. And by leveraging this assumption, we can make tools better for those who know basic English. I believe that while jokes make commands easier to memorize, the time to memorize the command name is so short that it doesn't matter in the long run, and there is a significant cognitive load in reading scripts made mostly of random funny names, as opposed to scripts containing names that are fairly good first approximation of their actual meaning.
(We all agree that the CLI is a h4X0r interface, right?).
No.
A library, a complex computer language needs some internal consistency, then having meaningful function and variable names is a plus. No to strcat, strncat, strcpy, strncpy etc. (because they're easily confused). I'm for camel casing by the way. It's cleaner, it better separates each word, etc.
It's unfortunate that you have to deal with English but that's the way it is
There is nothing unfortunate in dealing with English unless you're French or otherwise have a deep hatred for everything English.
for an English speaker, it's natural that stuff has the name it has
Hahaha, no. The names we use in IT have very loose correlation to their original meaning outside IT. Sometimes, native English speakers have it worse than non-speakers - because some programming languages sound very similar to natural English, but the meaning is completely at odds! (Try
if x is 0 or 1in Python.) Regardless of whether programmer knows English or not, they must learn the programming language pretty much the same way - memorize keywords, memorize grammar. And memorizing words is just as difficult when you know it from other uses as when it's brand new.the others just learn the word without necessarily understanding it.
They do understand it. In the context of their work. Knowledge of any other meaning of the word is unhelpful at best and misleading at worst. You don't need to know the Latin roots of word "person" to understand what it means in English, just like you don't need to know the English meaning of "include" to know what it means in C.
The game is "LOADING", not loading.
Yep, and that's good enough. Fun fact: to this day, I still read it as "lo-ah-ding" in my head. Usually I remember to say it correctly when speaking.
I remember my first Polish-language video game. I was very confused why it said "wczytywanie" on loading screen. It didn't make any sense to use it there. And it's not because it's bad translation - it's because the word "loading" is never used like that outside computing. I'm sure English speakers were just as confused until they got used to this brand new meaning of an old word.
It's one more step and I think it leads to a potentially worse understanding of how a computer works. Remember that the language you speak shapes your mind).
This is exactly why I think using previously known words actually hinders your ability to understand how computers work.
Excel is meant to be used by people who may hate computers.
You're implying that advanced computer users like computers. I've been using computers my entire conscious life, I've got myself deep in guts of both Windows and Linux, I've used a dozen different programming languages, and I assure you that I absolutely despise computers with every cell of my body.
But yes, Excel is meant to be used by basic users without much knowledge of computers.
And they want the computer to behave as little as a computer as possible.
What do you mean by that? And whatever you mean, it's impossible in this case because Excel formulas inherently need to expose the worst bits of programming (arbitrary words with very curtailed meaning, strict grammar and little help when you get it wrong, not complaining about obviously wrong formula).
They have different requirements. They don't want to be developers, they use a computer because they have to or because it's convenient for their job, but have no interest in any design considerations. If you make the language as familiar to them as possible it's better.
Except the formula language will never be familiar unless they actually bother to learn it properly. It's not just language barrier; it's figuring out that
IF()'s arguments are condition subexpression and two result subexpressions, it's figuring out thatVLOOKUPmeans "show the value in n-th column of provided table, from the row where first cell equals provided argument" (the Polish name "WYSZUKAJ.PIONOWO" is just as unintuitive). Human language used for functions has minimal bearing on how well the learning process will go overall.Who cares about the (foreign? Why is he foreign anyway?) support worker who you hopefully never have to call?
No one cares, up until you inevitably have to call him, and he knows exactly how to solve your problem that blocks your entire work and potentally causes the company to lose tens of thousands USD if you don't solve it by 5PM EOB, but his solution doesn't work in your language. International megacorporations are fairly common nowadays, you know. And it's not the only scenario where you could need to translate Excel formula from one language to another - I've had to do this several times for my personal work because I wanted to use some advanced feature that there are simply no Polish tutorials available.
-
@admiral_p That what happens when your shitty-ass country sleeps through the computer revolution.
-
@blakeyrat at least we didn't sleep through the civil construction revolution of 500 BC, and we don't have to worry about the big bad wolf blowing our houses off the face of Earth.
-
@gąska said in Command Line vs. GUI on Linux:
@gurth said in Command Line vs. GUI on Linux:
Translating the function names would’ve helped a lot in getting people to adopt it, though.
Or maybe it didn't. But since it already happened, we can't test the alternative, so we'll never know!
That’s the lazy way out.
People will be more inclined to use things that they can at least read the words in/on, than things for which they can’t.
-
@gurth said in Command Line vs. GUI on Linux:
@gąska said in Command Line vs. GUI on Linux:
@gurth said in Command Line vs. GUI on Linux:
Translating the function names would’ve helped a lot in getting people to adopt it, though.
Or maybe it didn't. But since it already happened, we can't test the alternative, so we'll never know!
That’s the lazy way out.
The only non-lazy thing we could do is make a proper study, but it's impossible now to make a proper study of it (except maybe in middle Africa or some other uncivilized countries).
People will be more inclined to use things that they can at least read the words in/on, than things for which they can’t.
Are we talking about usability or marketing?
-
@gąska said in Command Line vs. GUI on Linux:
it creates major problems for people who switch from one dialect of Excel formulas to another, because all the words are suddenly something else, and because of how natural languages work, you can't just use the standard dictionary to figure out the translations.
Doesn’t Excel translate the formulas in a spreadsheet to the current system/program language when you open the file? (I don’t know, and because of Microsoft’s habit of hardcoding localizations into programs, I can’t just check by changing my system language.)
@gąska said in Command Line vs. GUI on Linux:
This is exactly why I think using previously known words actually hinders your ability to understand how computers work.
Is that why computer scientists had to invent words like “concatenate,” you think?
@gąska said in Command Line vs. GUI on Linux:
People will be more inclined to use things that they can at least read the words in/on, than things for which they can’t.
Are we talking about usability or marketing?
I’m talking about usability, but I’m sure marketing likes it too, because then they can advertise to people that they can actually understand this software.
-
@gurth said in Command Line vs. GUI on Linux:
@gąska said in Command Line vs. GUI on Linux:
it creates major problems for people who switch from one dialect of Excel formulas to another, because all the words are suddenly something else, and because of how natural languages work, you can't just use the standard dictionary to figure out the translations.
Doesn’t Excel translate the formulas in a spreadsheet to the current system/program language when you open the file? (I don’t know, and because of Microsoft’s habit of hardcoding localizations into programs, I can’t just check by changing my system language.)
AFAIK it serializes formulas to common language-independent form, but that's not what I'm talking about - I'm talking about other text sources (like websites) where you might find Excel formulas.
@gąska said in Command Line vs. GUI on Linux:
This is exactly why I think using previously known words actually hinders your ability to understand how computers work.
Is that why computer scientists had to invent words like “concatenate,” you think?
They had to invent something. And eventually run out of pre-existing words used by no one, and didn't have enough surnames to name things after (common workaround in other disciplines).
@gąska said in Command Line vs. GUI on Linux:
People will be more inclined to use things that they can at least read the words in/on, than things for which they can’t.
Are we talking about usability or marketing?
I’m talking about usability
Then I'll tell you that the upfront familiarity with words has little (if any) impact on usability. Usability is about features being as easy and frustration-free to use by target user as possible, and letting them rely on wrong definitions of words is detrimental to this goal. And almost every word used in IT has a second, more common meaning completely unlike its meaning in IT (they only make sense through very loose metaphors and lots of hand waving).
-
@gąska I'm sorry, but I really don't get your complaint. You are an "Excel expert" I suppose? (Even if you aren't, you routinely work with Excel?). Do you fix stuff looking them up on Stack Overflow? And even if you do, what's the big deal in just taking the formulas that don't work, translate the functions to their English version (which is not a big deal) and then google that? Yeah, it's a further step. Life sucks for all of us. (And anyway megacorporations should have support teams who actually speak their workers language, how do you deal with support requests otherwise? "Help, Excel no work. Please fix"?)
-
@admiral_p said in Command Line vs. GUI on Linux:
@gąska I'm sorry, but I really don't get your complaint. You are an "Excel expert" I suppose?
Nope.
(Even if you aren't, you routinely work with Excel?).
Used to.
Do you fix stuff looking them up on Stack Overflow?
Not SO, but there were a few times I could only google up the solution to my problem on foreign sites, and I couldn't find translations of all functions used (the Microsoft Terminology Search didn't show up in Google results, and other sites had very short lists). I think I've lost entire evening once browsing through index of all Excel functions.
And even if you do, what's the big deal in just taking the formulas that don't work, translate the functions to their English version (which is not a big deal)
Except when it is. And when it isn't, it's still very annoying.
Yeah, it's a further step. Life sucks for all of us.
The beauty of theoretical discussions is that we don't have to agree to it! I don't expect the world to change because of our argument - I'm just saying why localizing function names was a mistake - it created some big usability issues with no gain.
(And anyway megacorporations should have support teams who actually speak their workers language, how do you deal with support requests otherwise? "Help, Excel no work. Please fix"?)
Yep, that's it. Most corporations have prikaz to always use English for all internal communication (except when you're 100% sure everyone speaks another common language, which usually means "only people in your building, except those few transfers"). It's not as bad as it sounds at first, because most people working in international corporations are able to communicate in English without too much trouble (that's usually one of job requirements, so no surprise here).
You know that scene from IT Crowd with Indian helpdesk? At my previous workplace, I've accidentally reenacted it almost exactly with our tech support when Office uninstalled itself from my desktop. Eventually the help desk guy remoted into my machine and we continued communication via Notepad.
-
@admiral_p
No it is the other way around. All English solutions and information is useless because Excel messages, errors and even the damn names are in moon language that doesn't correlate to the available information.
-
You have the privilege of having been able to learn English and being at ease speaking English. Meanwhile, a maybe more talented coder than you might be hindered by an inability to comprehend English easily so that he has more trouble evolving.or keeping up to speed. This actually happens in real life by the way.
Sorry, but I always get extremely angry when I hear or read things like that. Like, if we were sitting in a coffee shop, I'd be very compelled to pour my latte onto your head or do something equally silly. Let me explain why.
First, being talented is very subjective. It's general consensus that if something is physically possible to do — you're not missing neurons, or limbs, or muscles, or tendons — you're able to do it with enough practice if you feel like it (which is a major factor in it all). "Talent" is unmeasurable while it cannot manifest itself, and when there is output, "talent" is indistinguishable, or even inferior to, hard work, constant practice, and persistence.
I may be a very talented ballet dancer, but I will never know because I'm fat and lazy and I plain don't like dancing. Or, maybe, I have an innate talent of making stone arrowheads, I was just born at a wrong age. And you're extremely talented at sensing some X-field which is to be discovered in 256 years time. The "talent" is 90% bullshit, 5% pure physical ability, 5% genetic predisposition (yeah, I know there are people who are sort of born with superior baseball playing abilities because they've got some lucky genes which make their reflexes top notch; none of this applies to math, computering, and basic reasoning).
I was born in the USSR, and that country gave birth to some computering experiments including programming languages where all keywords were in Russian. These programming languages sounded extremely unnatural, and their keywords were perceived as labels at best. Most programmers who had any clue learned imperialistic western programming languages as soon as they could lay their hands on them. (Note: most programmers at the start of the 90s didn't know much English, but several dozen function names and keywords for some unexplicable reason hasn't confused them.)
There is still one language like that alive, invented for a bookkeeping platform which pretty much follows your pattern of "catering to a bookkeeper who doesn't know English". But guess what: bookkeepers don't grow into coders very well, and there is a caste of programmers who sell their services to them. Moreover: the code, even written in that funny Russian Visual Basic, still looks very code to them. They don't understand what it does, even though it's written using words they know. Why does it happen? Why haven't we found a coding demigod among bookkeepers yet, who ascended by virtue of being able to program without shackles of English words in the code? Maybe because it doesn't work like this?
-
@wft In my experience, there is such a thing as talent. But it only really has an effect at the bleeding edge. For 90% of cases, proper hard work beats lazy talent hands down. At lower complexity levels, talent is a force multiplier--it makes each unit of work yield more learning/output. At very high complexity levels, someone with less talent simply can't keep up (the work required >> the time available). Most things happen at the lower levels that anyone can reach with a little effort.
I was blessed to pick up anything word-related very easily. Words are my playground. And for that I'm grateful. Doesn't mean you need to be "talented" to handle 90% of all tasks. And these accusations of "privilege" are bunk, especially when deployed against strangers. @admiral_p has no clue who we are. I've seen people with severe dyslexia do great things. Claiming "oh, I'm just no good at that, so I can't do it" is what I see from my students. And it's a self-fulfilling prophecy that's completely unnecessary and self-inflicted.
There's a sweet spot on most learning curves--the inflection point in the amount of effort needed to reach the next level of understanding.
-
Pic related:
-
@gąska said in Command Line vs. GUI on Linux:
AFAIK it serializes formulas to common language-independent form, but that's not what I'm talking about - I'm talking about other text sources (like websites) where you might find Excel formulas.
So your argument is that no computer should ever be in a language other than English because that avoids problems looking stuff up?
Is that why computer scientists had to invent words like “concatenate,” you think?
They had to invent something.
How about “join” for this particular example? That’s a lot clearer than “concatenate” even to people who do speak English as a first language, never mind everyone else. (The reason I keep using that word as an example is because it had me stumped the first bunch of times I encountered it, until I managed to remember that, when talking about strings, it meant “join” or “add together” or “stick one after the other”. You’re not telling me that native English speakers wouldn’t have the same confusion.)
And eventually run out of pre-existing words used by no one, and didn't have enough surnames to name things after (common workaround in other disciplines).
Why would they need to find unused or invent new words to name things when talking about a concept that has clear analogs in everyday language?
Then I'll tell you that the upfront familiarity with words has little (if any) impact on usability. Usability is about features being as easy and frustration-free to use by target user as possible, and letting them rely on wrong definitions of words is detrimental to this goal.
So … it doesn’t help usability if a menu item says “Plik” instead of “File”? Then why not go the whole distance and make English-speakers also see text that makes no sense to them, like, I don’t know, just numbering everything? “To open a document, click the menu number 1, then choose the option labelled ‘4’.”
And almost every word used in IT has a second, more common meaning completely unlike its meaning in IT (they only make sense through very loose metaphors and lots of hand waving).
Yes, like
ROUNDDOWN()andSUM().
-
@wft see, look at talent as a model, like we often do in physics. It's not necessarily what really happens but it works as a model. Talent is a combination of disposition and chance (things that happened while growing up that shaped you), and it needs application and practice to translate into actual prowess. (I reject the notion that it's simply all hard work, it's reactionary, Calvinist drivel that serves to morally justify those at the top). I have never said that not knowing English makes programming impossible, but when everything is in English (everything) the world of programming can be perceived as "alien" right from the start.
Of course the programming language itself is a very minor element in the whole matter (it's all the rest that really makes a difference, even the fact that regional forums and discussion boards are usually, in my experience, shite compared to the international ones, with low quality comments etc. so the non-English speaking community is shite too), but everything counts in my opinion. It all adds up in ways you don't necessarily perceive (and you certainly don't because words aren't a problem for you). You're so obsessed with usability over here and you don't see that regular people can be put off by having to interact with words in another language (how can you put the hours of practice in, if your impact with the stuff is less than pleasurable?), and that having those metaphors, concepts in your own language can help you actually understand what it's all about sooner and easier, that is, when you are at the start? You know how much of teaching is very hand-wavey ("This does this, that does that, and you do this because [oversimplification]"). Getting those metaphors is part of what makes a good software engineer. You can still be a very good coder but it's different. Anyway it was a very marginal point in the argument and I don't see why you're all fixating over it.
-
@gurth said in Command Line vs. GUI on Linux:
@gąska said in Command Line vs. GUI on Linux:
AFAIK it serializes formulas to common language-independent form, but that's not what I'm talking about - I'm talking about other text sources (like websites) where you might find Excel formulas.
So your argument is that no computer should ever be in a language other than English because that avoids problems looking stuff up?
No, I'm saying that if you're making a programming language (and Excel formulas are programming language), making localized variants of the language doesn't help anyone and only pisses off people who have to deal with consequences of there being so many variants of this language. None of this applies to UI.
Is that why computer scientists had to invent words like “concatenate,” you think?
They had to invent something.
How about “join” for this particular example?
Who cares? They could have made it "birdie" 60 years ago, and by now it would feel just as natural as "concat".
And eventually run out of pre-existing words used by no one, and didn't have enough surnames to name things after (common workaround in other disciplines).
Why would they need to find unused or invent new words to name things when talking about a concept that has clear analogs in everyday language?
Because there's actually very few analogues that actually work. Case in point: thread. In real life, a string that you wrap around thousands of times to make clothes. In computing, a single set of instructions to execute in order along with allocated memory specific to this thread. Window: a glass separator between the inside and the outside or between two rooms, or a working space for a program to draw its GUI in that can be moved around or resized. They're not good metaphors; we just got used to them.
Then I'll tell you that the upfront familiarity with words has little (if any) impact on usability. Usability is about features being as easy and frustration-free to use by target user as possible, and letting them rely on wrong definitions of words is detrimental to this goal.
So … it doesn’t help usability if a menu item says “Plik” instead of “File”?
It helps, because it's UI and not programming language.
And almost every word used in IT has a second, more common meaning completely unlike its meaning in IT (they only make sense through very loose metaphors and lots of hand waving).
Yes, like
ROUNDDOWN()andSUM().You mean "floor" and "aggregate"? I said IT, not Excel.
-
@admiral_p said in Command Line vs. GUI on Linux:
Anyway it was a very marginal point in the argument and I don't see why you're all fixating over it.
Many of the people who are actually good at programming are also inclined to obsess over minor details; being good at detail helps a lot with getting the programming side of things right. (Understanding what the program should be doing from the users' perspective is a different thing, of course.)
-
@benjamin-hall said in Command Line vs. GUI on Linux:
And these accusations of "privilege" are bunk, especially when deployed against strangers. @admiral_p has no clue who we are.
I only said that if somebody can read, write and converse in English at high levels he is privileged. I'm an English teacher and I know, I very well know, that there are people who get it and people who don't. Application is key, of course, but for many people, there is no joy in learning languages. Other people are lucky to actually like learning languages and have an edge over them. The latter group aren't necessarily more gifted, it's just that they actually like Anglosaxon culture (and English and/or American humour), they like watching, say, movies or TV series in English and not the local dub, etc. Other people have no fascination with anything English-related and they study English just because they have to (and they're invariably shite). And you may think that "just apply yourself and stop whining" but that's easy to say when things come easy to you.
-
@admiral_p okay, but how's that relevant to anything discussed here?
-
@gąska it's relevant to the quote.
-
@gąska said in Command Line vs. GUI on Linux:
How about “join” for this particular example?
Who cares? They could have made it "birdie" 60 years ago, and by now it would feel just as natural as "concat”.
That word doesn’t feel natural to me. (Then again, many terms of American origin seem overly complex to me. They never seem able to just give a name to something, but always need a lengthy descriptor that they can then abbreviate, and preferably they come up with the abbreviation first and fit a convoluted descriptor to it.)
Because there's actually very few analogues that actually work. Case in point: thread. In real life, a string that you wrap around thousands of times to make clothes. In computing, a single set of instructions to execute in order along with allocated memory specific to this thread.
Or maybe, the word “thread” in programming derives from analogy to “the thread of this conversation”.
Window: a glass separator between the inside and the outside or between two rooms, or a working space for a program to draw its GUI in that can be moved around or resized.
Yes, like
ROUNDDOWN()andSUM().You mean "floor" and "aggregate"? I said IT, not Excel.
We’re talking about different things, that comment made me realise. I’m talking about computer use in general, and specifically spreadsheet formulas, and you’re talking about programming languages.
Yes, spreadsheet formulas are a programming language of kinds, but the important difference that you don’t seem to want to recognise is that they are intended to be (and are) used by people who are not programmers. By making the keywords more like normal language (whichever one), the chances of someone stumbling across the right one are greater, if you ask me. “I want to get the sum of the values in these cells …” They’re more likely to think of trying, or looking for,
SUM()than forAGGREGATE(). This problem only gets worse if they have to do it in another language, never mind both.
-
@gurth said in Command Line vs. GUI on Linux:
So … it doesn’t help usability if a menu item says “Plik” instead of “File”? Then why not go the whole distance and make English-speakers also see text that makes no sense to them, like, I don’t know, just numbering everything? “To open a document, click the menu number 1, then choose the option labelled ‘4’.”
Have you tried SSDS?
-
@gąska said in Command Line vs. GUI on Linux:
Because there's actually very few analogues that actually work. Case in point: thread. In real life, a string that you wrap around thousands of times to make clothes. In computing, a single set of instructions to execute in order along with allocated memory specific to this thread. Window: a glass separator between the inside and the outside or between two rooms, or a working space for a program to draw its GUI in that can be moved around or resized. They're not good metaphors; we just got used to them.
You sound like blakey here, picking a particular definition and never considering anything else. And it's kind of funny because you were so close on threads. Because you weave then all together, over and under reach other, but you can follow reach stand as it's open thing, separate from the others.
A window had a frame and everything into it gives you a view into something different. The metaphors are fine for what they are.
-
