Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.
Its ok to have more advanced topic that require more knowledge and that people don’t understand from the first moment they see them.
Software was a mistake
Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.
Don’t even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined … but that was wrong. JavaScript is fine, C# is fine … as long as you don’t stop there.
(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney’s first published game, back when Epic Games was called Potomac Computer Systems. It doesn’t have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn’t cause brain damage, no language will.)
Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”. So what if the first language you used required curly braces, and the next one you learn doesn’t? So what if type inference means that you don’t have to write
inton your ints? You’ll get used to it.You learned how to use curly braces, and you’ll learn how to use something else too. You’re smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.
I still think ruby is a bad language, even though I agree with you
I found ruby horribly confusing until I got over the intial learning bump.
Now I love it. It really is lovely. In terms of design that is. Not sure about the monkeypatching
I really don’t like how rails brings things into scope and you just have no idea what’s there or how it got there unless you know all of the conventions. I guess that’s a rails issue and not ruby though.
I learned in python and C++ so I’m biased towards things that are extremely specific. Definitely doesn’t mean ruby is necessarily bad, I just don’t like it.
I’m one of those weirdoes who likes ruby and has never used rails, so no opinion there.
ZZT-OOP is fun to work with though, definitely not meant for doing anything more complex than light gameplay, and yet people have done ridiculous things with it.
Though I personally did most of my coding in that vein in MegaZeux with their Robotic language, which is basically ZZT-OOP++.
Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”…The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.
Well i mean… that’s kinda what “unintuitive” means. Intuitive, i.e. natural/obvious/without effort. Having to gain familiarity sorta literally means it’s not that, thus unintuitive.
I dont disagree with your sentiment, but these people are using the correct term. For example, python len(object) instead of obj.len() trips me up to this day because 99% of the time i think [thing] -> [action], and most language constructs encourage that. If I still regularly type an object name, and then have to scroll the cursor back over and type “len(”, i cant possibly be using my intuition. It’s not the language’s “fault” - because it’s not really “wrong” - but it is unintuitive.
No programming language is “natural/obvious/without effort”.
You could say that about anything. Of course you have to learn something the first time and it’s “unintuitive” then. Intuition is literally an expectation based on prior experience.
Intuitive patterns exist in programming languages. For example, most conditionals are denoted with “if”, “else”, and “while”. You would find it intuitive if a new programming language adhered to that. You’d find it unintuitive if the conditionals were denoted with “dnwwkcoeo”, “wowpekg cneo”, and “coebemal”.
Languages also have inner consistency. E.g. the mentioned python len function is inconsistent with the rest of the same language - and that is a statement that is true in itself, without an external reference point.
Yes, I agree that the
len()thing in Python, and inconsistency in general, is bad. But pretty much all popular languages have many inconsistencies.
But there are languages that require varying degrees of effort to become natural. Something like Malbolge will pretty much never be natural while something like Python can become natural to you in a few days.
Yeah. The original comment was about programmers who say that a language is “unintuitive” because it doesn’t look like another language they know.
If you only know C and you’re looking at Python, the absence of curly braces on code blocks is temporarily unfamiliar to you.
But if you only know Python and you’re looking at C, the fact that indentation doesn’t matter is temporarily unfamiliar to you.
Once you learn the new language, it’s not unfamiliar to you anymore.
“Unintuitive” often suggests that there’s something wrong with the language in a global sense, just because it doesn’t look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.
“Unintuitive” often suggests that there’s something wrong with the language in a global sense
I mean only if you consider “Intuition” to be some monolithic, static thing that’s also identical for everyone. Everyone has their own intuition, and their intuition changes over time. Intuition is akin to an opinion - it’s built up based on your own past experiences.
just because it doesn’t look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.
I don’t think it’s that deep. All people mean when they say it is that “[thing] defied my expectation/prior experience”. It’s like saying “sea food tastes bad”. There’s an implicit “to me” at the end, it’s obvious i’m not saying “sea food factually tastes bad, and anyone who says they like it is wrong or lying”.
This is very true! Languages being unintuitive also becomes less of an issue the more languages you look into. There will be many concepts that multiple languages have since ultimately they are all trying to do similar things and the more you learn the more you will recognize making it easier to get into even more languages.
Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.
This is wise advice for ANY domain of knowledge.
Lotta people get a little fragment of knowledge on something, then shut down their brain and stop accepting new input. But life is change, and to be able to change and learn new things you need to keep your mind open. Being able to relax on having opinions and keep learning and moving along is very important.
Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”.
Yeah. I’ve written in six or so different languages and am using Go now for the first time. Even then, I’m trying to be optimistic and acknowledge things are just different or annoying for me. It doesn’t mean anything is wrong with the language.
Idk, I don’t see a problem with saying a new language is unintuitive. For example, in js I still consider the horrible type coercion and the “fix” with the triple-equals very unintuitive indeed. On the flip side, when learning C# I found the multiple ways of making comparisons to be pretty intuitive, and not footguns.
DRY means Do Repeat Yourself, when the alternative is cooking up some awful OOP abstraction
Designing good UX can be as difficult as writing good code.
Source: Im UI/UX designer and project manager and also QA/QC and also devops and also write the specs and documentation. The only thing I dont do is write the code, DB schema and architecture . The hardest of all those roles is UX. The easiest is project management ("Did anything go tits-up today? No? Well carry on, then ")
Biases: I have no formal training in any of those things and was actually hired as a helpdesk tech.
Tabs are better than spaces
Answering my own question here. If you don’t have any interest in how the tools you use work, programming isn’t “for you” (take that with a grain of salt). If you are writing code and have never looked into how compilers/interpreters work or are using a library and haven’t even taken a peak at the library’s source code you should because it will make you a better programmer in the long run. And I’m not saying you can’t get anything done without that curiosity but curiosity is a major part of being a programmer. Also you don’t need to have a deep understanding of the tool just a overview of what it’s doing. Like for a compiler understanding what lexers, parsers, ASTs, code generators are will allow you to write code with that in mind.
Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There’s a certain kind of dev that just gets a superiority complex about using CLI stuff.
I don’t know, a tool we use at my work has a git GUI integrated, and it breaks all the time, lol.
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
- The terminal can remember everything you ever did. Forgotten the command you wrote 2 months ago? You can do a search for it with a tool like
fzfand run the exact same command again. - Communicating with others. GUI programs require step by step instructions, often accompanied by screenshots while CLI may be copy/pasted.
- Combining programs together. There are a few different techniques for combining CLI programs to search/format output, use secrets without ever having them in the clipboard or on disk, monitor something frequently/constantly etc etc
So while I agree with you that there’s plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
- The terminal can remember everything you ever did. Forgotten the command you wrote 2 months ago? You can do a search for it with a tool like
This depends a lot on the GUI and the tool. Some cli tools are great alone or for scripting, others benefit from the extra attention to ux and exposure of options that a GUI can offer
For git in particular, I encourage juniors to learn and use the CLI. I find that GUI git clients often do some or all of the following:
-
Use non-git terminology that ends up being confusing. “Sync” comes to mind as a frequent offender, I can think of several incompatible things that could refer to.
-
Ignore the useful ability to stage your changes
-
Don’t permit or encourage a review of the changes
-
Implement only the basics and make remediation of branching issues difficult
In the worst case, I’ve seen people end up using the git GUI like a “save” button, blindly commiting and pushing the current state of their code, including to-be-removed print statements and other cruft. Yeah, git cli is a bit complex compared to that, but you gain a lot for that added complexity.
That said, I’ve definitely jumped into a git GUI from time to time just for a visualization of whenever branching snafu I’m trying to untangle. None of the above invalidates GUIs if you take care to still understand the underlying tool properly!
-
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
That said, jetbrains git integration is awesome.
I’d argue the GUI has the lowest barrier to entry as it eliminates the need to learn any syntax or look up which switches to use.
If someone use a particular CLI tool often it can be quick and easy to do something, but for the occasional use, a GUI is much easier, assuming it has the required features a person needs. Can I use sed to replace a bunch of text in a file, sure, but it’s probably be faster and easier to use a text editor since I’m not using sed everyday.
It also depends on the specifics — in many cases when a GUI is just a wrapper over the CLI tool, it is instructive to learn the CLI, similarly how you are a better programmer if you know about at least a layer beneath the one you are programming at (e.g. you can reason about this usage of hashmap because you roughly know what it does).
It is probably the most visible in git, but if you can only do commit and push from a GUI, just please learn the CLI as well. You don’t have to use it, but understanding it is important and the GUI may abstract away too much from you.
I agree, for a power user there is some value there.
I’ve used the git CLI, but find it a bit tedious. I also find a lot of value in the GUI providing an easy diff reference before a commit, at least in the app I use most of the time. There are some things the GUI can’t do, or it’s too weird to do, so the CLI is still handy.
I agree only when your job function is specifically geared around those tools… Otherwise high quality guis are more valuable.
Just because I can do everything in gdb that I can do in visual studio doesn’t mean 99% of most debugging tasks isn’t easier and faster in visual studio. Now if my job was specifically aimed at debugging/reverse engineering there are certain things that gdb does better on the CLI… But for most software devs… CLI gdb isn’t valuable.
The big thing you can do from the command line is script it.
Which means a person doesn’t need to become that good with the command line, they just need to learn the commands long enough to write the script and then never think about those commands again.
I’ve written a lot of scripts, but if someone asked me to do what the script does at the CLI with no man pages or anything, nope. Can’t do it, and I think that’s probably a good thing.
My file explorer has a GUI and is scriptable ;)
Indeed, the problem with gui apps is when you can’t script them!
I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….
Just no. CLI can be automated, which makes it superior. It’s not a superiority complex, it’s a fact. I’m not a minimal wage worker pushing buttons I don’t understand. I’m not a technician who learnt your shitty software to do the most basic tasks.
Aside from automation, CLI can support significantly more complicated apps reliably. It can also be tested more reliably.
GUIs are better for anything simple, and good UX designers can make a moderately complex one, but anything like server administration/git/configs are 100x better on CLI
My gold standard app is a CLI where I have the option to visually add the flags. I’m thinking of the ytdlp-gui type programs.
Which yt-dlp GUI do you use?
On windows I was using youtube-dl-wpf
That’s the gold standard as far as I’m concerned. Haven’t used the ytdlp-gui yet, but it’s simple stupid… I might want a few more switches (more exactly the extract audio/subtitles) to turn
I’m not convinced that “strong pairing” is the best way to pair but even people who rail against agile ideology tell you that you’re pairing wrong if you don’t follow it precisely.
Front end and back end are different enough that you can really specialize in one or the other. They take very different mindsets. I know how to make css obey, I don’t know how to make sql performant. Its possible to have both, but not as well.
For every front-end dev, you need 3 back-end guys and a designer.
Programmers are not bad at our jobs, its just not a mature disclipline yet.
I don’t agree and I don’t disagree, but I thinkcontext matters a lot here. Some teams and codebases need deep knowledge, some don’t. Some nned sql performance, some don’t. Your conclusion is only true some of the time
It’s not mature, because nobody let it mature.
Programming is over 70 years old, that’s not a new discipline. Yet, the engineering in our industry is still abysmal. Countless reinvented wheels, nothing is ever finished, changes happen often enough for the sake of change, not progress.
That’s part of the nature of programming. Half-finished might be good enough. If you’ve made an awesome wheel but I need a kink in one of my spokes and yours doesn’t do that, making my own wheel might be cheaper than modding yours.
OTOH, there’s nothing more frustrating than looking for a particular wheel, finding ten really great ones that collectively have the features you need, but individually aren’t good enough.
To stay in the analogy: usually we just want to transport things from a to b. It doesn’t matter, how we get there. So usually we begin with a road and start to cobble together a vehicle from barely fitting and functioning junk we find on the roadside.
There’s hardly any stable surface to work on. And that’s extremely costly.
Abstraction will be the death of traditional software development as we know it
Most frameworks are garbage and most programmers that use them have no idea how they work and that makes them shitty programmers. I hate when people use frameworks without even knowing why they’re using them.
Hey us programmers only listen to our engineers or architects. Blame them.
It drives me nuts when someone on SO asked a question about JS and all the answers use jQuery. It’s not as much of an issue these days, but for a while it was almost every post. I really questioned if people knew the difference.
For their credit basic javascript is a garbage language.
Sure, but there is nothing jQuery can do that basic JS can’t, just with extra steps.
I was working in an environment where jQuery (or other frameworks for that matter) couldn’t be used, so I had to cut my own path most of the time. I learned a lot about JS and CSS that probably would have been obscured away behind jQuery and Bootstrap had I not had those restrictions.
If someone is asking for a solution in a particular way, there is often a reason. Too many people skip that and provide it in what they know or are currently using, instead of what the user needs. These days I can imagine someone needing help changing the text on a button and someone telling them they need React, with some overly complicated solution to just and prove how smart they are, when all the user needed was how to set the innerHTML on their button element.
Oh I agree that questions are two often badly answered! The exemple of “why don’t you use this instead” is the worst offender. I didn’t understand you were talking about this, and I’m still traumatised by javascript after 14 years.
Yes…and, worse yet, the jQuery responses are almost never a good way to do things or they use things that are deprecated. It’s a hot mess out there.
Are you talking about JS or in general?
deleted by creator
You can never have too many children
Programming is actually hard af to do for any extended period of time (more than half an hour)
It requires such a specific mind that’s drawn to all the detail oriented specific robotic parts of coding but almost all coders say coding is easy because the people whose mind don’t fit coding already quit long ago
Yes I find coding hard and no I’m not coping
Actually programming being difficult might not be correct but more like programming is largely unbearable
