DEV Community

Discussion on: Six Things You Thought Senior Devs Did (But We Don't)

 
val_baca profile image
Valentin Baca

Sorry, this turned into a bit of a rambling rant. I might make a post about languages in general! haha

For me, Rust falls below the line for languages I want in my toolbox. That's not to say I think it's bad, it just doesn't fit the problems I'm working on. The reason I was looking at it was because I wanted to improve a particular command-line tool that I was using and wanted to get a sense of whether it would be too difficult to do or not.

It's perfectly valid to feel overwhelmed with the # of languages floating around and feel like we'd be better off consolidating rather than repeating.

When I look at a language like C++ or Python, it's clear to see the harm that piling on features to an existing language can do.

I will say that the Rust community is one that really loves their language in a way that I don't see that often and the language does seem to excel at the promise of extreme speed with safety and efficiency.

There's a ton of factors that go into language popularity: corporate backing, ease of use, fitting a niche but not being too narrow. Then, popularity becomes a positive feedback loop because the more popular a language is the more libraries and integrations are written for it, which increases popularity etc. We saw this with how Ruby blew up with Rails and Python with numpy, TensorFlow, etc. Java was the behemoth it was/is because of Sun/Oracle, while capitalizing on the promises of the JVM (which were met IMO) and filling the corporate server niche. That led to it being the language of choice for Android, which made it even more relevant, etc. etc. etc.

But a lot of what the languages give was all discovered decades before with Lisp. So why didn't it just take over the world? Well that's a whole other post.

In summary, from what I can tell, the Rust languages is evolving fast, has a community that loves it, and is filling a niche for systems programmers who want speed and safety.

I imagine you feel towards Ada-and-Rust as I feel a bit toward Java-and-Go. I picked up Go to learn it and found it not really doing much different than Java. Go's getting Generics; Java had that a decade ago.

That said, I really did find that Go just got out of my way and let me code what I need to.

It's also totally reasonable to always have a "hype buffer." It's okay to watch if something will stick around. If it's going to stick around then it'll still be there! If not then maybe you missed being on the first hype-train, but you can't get on every one.

Thread Thread
 
jmccabe profile image
John McCabe

FWIW - generics; not that I know much about Go's, nothing at all, but generics were in Ada when it was released to the public in 1983. I think it's fair to say there's nothing new in languages, just different, but different for the sake of being different doesn't cut it for me. :-)

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

When I look at a language...Python, it's clear to see the harm that piling on features to an existing language can do.

I dunno, Python is my primary language, and I do not see this at all. I, like most of my fellow Pythonistas, love Python with all the passion Rust coders love their language with. I think it's an opinion thing.

Thread Thread
 
jmccabe profile image
John McCabe • Edited

I'm not a big fan of python (nor any language where a slice/range written as 2:5 gives you elements 2, 3 and 4, but NOT 5), but I use it quite a lot for quick and dirty scripting. As far as I can tell, it took the best part of 10 years for Python 3 to overtake Python 2 in usage, almost solely as a result of a rash decision to make 3 substantially incompatible at the source level. I think that did Python a lot of harm. Contrast that to the Ada 83 - > 95 update, whose goal was to provide new features while keeping incompatibilities to a minimum (archive.adaic.com/intro/tech/8395c...).

In my opinion, this highlights how many language authors (I hesitate to call them designers) chuck something out there prematurely with the hit, in terms of language churn, being taken by the users.

Java, in its early days, was a prime example whereby a ton of breaking changes were made on every new revision. Sadly, following a few years of relative stability, Java sounds like it's reverting (admittedly based on what I've read, as opposed to using it) and C++ is getting out of hand with numerous half-baked features going in, with disappointing implementations, and the promise of more 'improvements' in the next revision, 3 years down the line.

Two things I'd been looking forward to in 'modern C++' were enum class and std::array, my hope being that, somehow, they'd manage to implement something almost matching the power and expressiveness of Ada arrays from 35 years earlier. Sadly, no. std::array is pretty much a wrapper round a C array, is almost impossible to create without a constant size, and still uses zero-based indexing at the source code level. enum class doesn't even match Java's enum in usefulness.

In addition to that, I watched part of a video where Herb Sutter was talking about potentially introducing 'interfaces' and asked a couple of audience members what they thought the default visibility of the methods and attributes in the example he showed them would be. When he went on to ask if they thought it would be a good idea if methods were public, by default, and attributes private, they agreed! You have a language that already confuses some people by having two composite type mechanisms, class and struct, with different default visibility of ALL members, and now you want to introduce a 3rd, abstract one, with different visibility depending on whether it's a method or an attribute? They must be out of their tiny minds.

As far as I can see, the people involved in the C++ revisions appear to have lost sight of the fact that bigger and bigger software systems don't need more and more complicated and confusing features and syntax; they need more clarity, simplicity and expressiveness as you can't expect all the people working on these systems to know a language as excessive as C++ inside out.

Sorry - went off track there. Python, yeah, I tend to believe Python is kind of in that mostly stable period; whether it will follow Java and C++ back to instability remains to be seen.

Thread Thread
 
val_baca profile image
Valentin Baca • Edited

I have to strongly disagree on how slices are handled. It's standard for the range to be [x,y), i.e. inclusive of the first index x and exclusive of the second index y. It gives you a consistent # of elements equal to (y-x). So (3,5) should give 2 elements (5-3) starting at 3.

Standard as in used across many languages (links to single examples from each): C++, Java, Javascript, Go

It's as ingrained as the standard for-loop: for (int i = 0; i < n; i++) which is effectively [0,n)

Slices aren't ranges. I see that Ada uses ranges, but they're distinct from ranges.

I also have to disagree that Java is unstable b/c it has features added with new features. I've done a lot of Java migrations, but they're relatively minor. Very few deprecations are breaking and for the most part you can take old code and just run it on the latest JVM.

Thread Thread
 
val_baca profile image
Valentin Baca

I was more referring to GvR leaving the language as leader: mail.python.org/pipermail/python-c...

I'll admit that a majority of my interaction with python has been migrating some ancient (5 years old) scripts from Python 2 to 3 and the experience was not pleasant.

Thread Thread
 
jmccabe profile image
John McCabe • Edited

I'm happy to bow to your superior knowledge of recent Java changes.

As for ranges etc, please check out the use of the range keyword and 'Range attribute in Ada. An array slice in Ada is a subsection of the array defined by a range.

Your suggestion of there being a 'standard' definition of a range in programming appears to be using references to languages that didn't exist when Ada had been using array slices and the range keyword and attribute for a number of years. Also, the suggestion of a 'standard' for loop makes no sense. The specific example you give is common to C, C++ and Java, at least, where array indices have not been abstracted away from machine representations. Even if you go back before Ada became an international standard, in 1983, it had introduced superior array handling that didn't rely on users managing (often badly) the mapping of array indices from the problem domain to the machine domain.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Most of us in the Python world see the transition from GvR's BDFL tenure, as good as he was, to the formal Steering Committee as a good thing. It's certainly brought a lot of improvements to the language, its internal development processes, and the community as a whole.

(Mind you, GvR is still very much involved, just with a layer of removedness that frees him up to pursue new ideas in Python w/ Microsoft funding.)

Python 3 was weird by nature of improving on some mighty weird things in Python 2, that lead to some things needing to be broken. That's why Python 2 wasn't deprecated until Python 3 was on full feature parity.

Thread Thread
 
val_baca profile image
Valentin Baca

That's good to hear. Thanks for your perspective!

Thread Thread
 
jmccabe profile image
John McCabe • Edited

Sorry for the late reply (and possibly in a weird place; I'm not sure Dev's threading implementation is as optimal as it could be) but I've only just found out that Ruby, see ruby-doc.org/core-2.5.1/Range.html, treats a 'range' as Ada does; inclusively, if you use the simple s..e format. An extra dot is required if you want to use the exclusive (i.e. not including the end index) version, s...e. In addition, if you use ::new to create a range, you need to explicitly specify the 3rd, 'exclude_end', parameter if you want the non-default, exclusive, behaviour.