I would guess that Ada is simply more known. Keep in mind that tech exploded in the past ~3.5 decades whereas those languages are much older and lost the popularity contest. If you ask most people about older languages, the replies other than the obvious C and (kind of wrong but well) C++ are getting thin really quickly. COBOL, Ada, Fortran, and Lisp are probably what people are aware of the most, but other than that?
The first five languages I learned back in the 70s: FORTRAN, Pascal, PL/I, SNOBOL, APL. Then I was an Ada and Icon programmer in the 80s. In the 90s, it was C/C++ and I just never had the enthusiasm for it.
Icon (which came from SNOBOL) is one of the few programming languages I consider to embody truly new ideas. (Lisp, Forth, and Prolog are others that come to mind.)
Icon is an amazing language and I wish it was better known.
You probably know this but, for anyone else who is interested, the easiest way to get a feel for Icon nowadays may be through its descendant Unicon which is available at unicon.org.
I found Pascal more readable as a budding programmer. Later on, C's ability to just get out of the way to program what I wanted trumped the Pascal's verbosity and opinionatedness.
I admit that the terseness of the syntax of C can be off-putting. Still, it's just syntax, I am sorry you were disuaded by it.
I dabbled in some of them during some periods when I took a break from work. And also some, during work, in my free time at home.
Pike, ElastiC (not a typo), Icon, Rebol (and later Red), Forth, Lisp, and a few others that I don't remember now.
Not all of those are from the same period, either.
Heck, I can even include Python and Ruby in the list, because I started using them (at different times, with Python being first) much before they became popular.
> But my main gripe with tabs is that no one agrees on the width.
That's the entire point of tabs. One tab means one indentation level and you as the user can decide how that's displayed. Spaces forces everyone to see the code exactly as whoever decided on his favourite width and that is in the best case "only" annoying to people with different preferences and in the worst case actively hurtful to people with disabilities.
The only argument spaces people ever have is "some of my colleagues are too stupid to properly indent with tabs and align with spaces" and that is trivially fixed by either of those:
- don't use alignment, it's useless anyway
- get better coworkers
- educate your coworkers
- use commit hooks to check wrong usage
So basically there is no argument left on the spaces side at all^[1]. Meanwhile tabs semantically mean "one indentation level", take up less bytes, and most importantly allow everyone to have their own preferences without affecting other people. And honestly I am insanely baffled by how many people don't get the importance of that last part. Accessibility like that costs you nothing but means the world to other people, similarly how we have ramps at public buildings for the elder, wheelchair users, strollers, and so on. And not to mention the fact that there are a lot of autistic people in programming, which often have a harder time dealing with things not being as they want them to be. Is there any reason to choose an objectively inferior method and force that onto those demographics just because "muh alignment"?
[1] Okay fine, there is one: "Tools I don't own don't display tabs as I want them, for example GitHub with their retarded default of 8". But first of all you can change that if you're logged in and second you're supposed to use your IDE and not a web interface...
I would agree that there aren't any arguments for spaces and would be 100% on the side of tabs, except for one problem: variable width means you can't enforce a maximum column limit.
Some people don't care about column limits, but they're important to me because I like to tile multiple editor panes side-by-side with no space wasted.
The entire debate is stupid anyway and should already be a solved problem. If we used tooling that operates on syntax trees instead of source text, then every developer could have exactly the formatting they want without conflicts. I don't know why that isn't more widespread; the only language I know of to do it is Unison.
Because a coworker might want (tabs*4 + chars) < $defined_width. Whatever multiplier you pick, it will either mean a too short or too long limit, and inconsistent limits between lines depending on how much indented a line is, if everyone uses a different tab size.
But I was addressing the the issue if enforcing column widths in a shared code base. I interpreted their statement as something like "you can't enforce column width in a code base with tabs".
But if someone changes their tab width, it's easy to check if it goes over 80, given a standard of 2 space tabs, and they use 1. Is they don't indent enough, that's harder.
I personally reformat code temporarily depending on what I'm doing, column width to me is a publishing standard, I don't care about it while I'm deep in the code.
Before the parent's edit it was about line length limits, IIRC. In any case that's what my comment was referring to. If you want to limit line length to, say, 100 characters (to visually fit within a 100-character wide window or terminal), then it matters what tab width you use. If you check it assuming a tab width of 8, someone working with a tab width of 2 will be limited to shorter lines the deeper the indentation level. Conversely, when the check assumes a tab width of 2, someone working with a tab width of 8 is likely to see lines longer than 100 characters although the lines passed the check.
Autistic or not, giving that kind of health information to private for-profit companies who collect that data to use it against you or sell to third parties was never a good idea even before the government wanted to take it for themselves.
There is a GitHub icon directly at the top right of the side so your first two steps can be combined into one shorter one. But yes, screenshots should absolutely be on the home page, and prominently so.
> I can't say why the scientists aren't flocking to Nim, but as someone who wants to support them wherever they go, it's why I'm uncertain if it was the right call.
Because most scientists are only using programming as a tool and don't care one bit about it beyond what they need it to do. They don't go looking for new tools all the time, they just ask their supervisor or colleague and then by default/network effects you get Python, Fortran, or C"++". You need a killer argument to convince them to do anything new. To most of them suggesting a new language is like suggesting to use a hammer of a different color to a smith - pointless. With enough time and effort you can certainly convince people, but even then it's hard. It took me years to convince even just one person to use matplotlib instead of gnuplot when I was working in academia. You can obviously put that on my lack of social skills, but still.
Well first of all, C++ is the language you'd be using to power a rocket engine. And second, that code is a terrible example because most of it isn't C++. Large parts of that are very C like or directly C because it's using the Windows API.
