1

For example, when working with arrays there are methods like indexOf() that works like this:

if (array.indexOf("something")!=-1) { // do something or nothing }

Why hasn't someone made a contains method?

if (array.contains("something")) { // do something or nothing }

Or add functions people find useful like:

var fileHeader:int = byteArray.indexOf([0xFF, 0x00]);

Or with strings or regular expressions:

if (String(myString).contains("fox")) { // do something or nothing }

In the E4X XML classes I see so many cases where things don't work or you have to know certain things. For example, there is no remove call in XML objects. Instead of xml.remove() you have to do this:

 delete xml.parent()[xml.name()][xml.childIndex()];

There are plenty of places where improvements could be made with core language classes but it seems they stagnate. Some things haven't changed in over 30 years.

Why is that and can we add better calls instead of using the rotting corpse of yesterdays API's?

I wish that these features were added.

  • 4
    Have you given any thought to backwards compatibility? – Robert Harvey Dec 23 '16 at 18:44
  • 2
    If you happen to be doomed to program with Swift you will loath the monthly development where the next iteration is almost completely incompatible with the previous one >:-( – qwerty_so Dec 23 '16 at 19:15
  • You're right. I should clarify that backwards compatibility is important to me too. I'm more focused on adding methods that make sense. In the example, indexOf is asking to find and return the position of a string in another string. It seems clever to check if the index is -1. If it is then you know that the string was not found. It's so clever! But to new developers and guys like me that have been doing this for 20yrs I tired of it. I just want a contains method. Is that too much to ask? – 1.21 gigawatts Dec 24 '16 at 1:06
  • @ThomasKilian: Add least it gives you lot of stackoverflow questions with easy answers... And I think Apple wants this language to stay around at least as long as Objective-C (30 years and counting), so improving things even if it breaks existing code is the better choice. – gnasher729 Dec 24 '16 at 18:29
  • @gnasher729 I'd rather wish they made it right the first time, but it's getting worse each iteration. This "ingenious" Optional, now conflated with a awkward exception handling from the back door. I can't wait for Swift 4.0 - Die Even Harder... – qwerty_so Dec 24 '16 at 18:41
12

It is mostly a (standard) library issue (in programming language parlance), not a core language issue.

Several programming languages have extra libraries improving them (or even replacing their standard libraries) like you wish (e.g. Boost for C++, Batteries or Core for Ocaml, JQuery for JavaScript).

A programming language designer has to balance two conflicting goals (or approaches):

  • providing a very complete standard library, but that is a huge amount of work (a prototypical example is Java)

  • providing a small standard library (only the minimum required to e.g. the compiler) to lower the effort and focus on the core language features, but then the programming language would in practice succeed only if the community develops many external libraries (both C, and to a lesser extent, Ocaml, come to mind)

I disagree with the "stubborn" adjective in your question: most programming languages have a very limited language developer community (and being able to design or develop a programming language is a quite rare and demanding skill); it is hard to get paid to design a programming language. So programming language designers have to make choices on the areas they will focus their effort on.

If you wish more standard library features in your favorite programming language, contribute to it (by your own labor - and that takes a lot of time, or by funding the programming language developers).

  • 1
    Just to note: jQuery doesn't replace or improve the JavaScript core, but rather the browser environment, most notably the DOM API. – John Dvorak Dec 23 '16 at 18:41
  • Agreed. But in practice, is JavaScript even worth existing outside of the browser? Things like node.js appeared because JavaScript was already very popular - in browsers. – Basile Starynkevitch Dec 23 '16 at 18:43
  • node.js exists for several reasons, but one of the most compelling ones is that you can use a single programming language for both client and server. – Robert Harvey Dec 23 '16 at 18:44
  • 2
    Yes, we agree. node.js exists only because JavaScript became popular in browsers. – Basile Starynkevitch Dec 23 '16 at 18:45
  • 1
    One benefit of node.js that isn't related to browser javascript is that it's event-driven rather than thread-driven. Also, Javascript has great scoping rules and a familiar syntax. – John Dvorak Dec 23 '16 at 18:45
3

You should be more clear about what you consider as an "upgrade" to a function. Do you mean to actually improve it's already existing implementation or add a new and better implementation ?

For improving implementation, it would be a bad idea. Think what would happen to an application you wrote on SDK version X and then deploy on a machine that runs an SDK with a higher version ? what would happen is that your functions may return different results on some edge cases and would provide unpredictable behavior, which will force you to either add support for that SDK version (no fun!) or tell your client to avoid that SDK (also no fun).

Many languages just add better implementations and function and just tell you to avoid the old ones to make your life easier. but they keep them around as legacy so your applications wouldn't break.

As for your example, instead of .contains, the Array.prototype.includes method exists and can replace .indexOf as you described it could.

But what if I still needed to use the function to actually find an index (I happen to like doing this as I'm getting my job done), instead of just figuring out it the array item exists ? I couldn't have done so with .contains, so for me, it's an inferior feature.

So languages only upgrade when there is a real necessity for it, otherwise it would have a huge, bloated, legacy of crappy unwanted features (javascript, php, etc..) So it would be best just to use libraries or API's that would provide you these "upgrades".

  • I wouldn't want any of my applications to break with new features so no, I wouldn't want to upgrade them if it broke anything. I'm not against adding new parameters for new options if it didn't break anything. But I would much rather have a new method added. – 1.21 gigawatts Dec 24 '16 at 0:22
  • You mentioned contains wouldn't be any use to you but I would argue that's useful to me. There are many times where all I need to know is if a string contains a word or match (using regex). I don't give a flying fish about getting the position. I just want to know, yes or no, one thing. It makes me irrationally angry (after 20 years) every time I type string.indexOf("x")!=-1 when I could just write string.contains("x"). But no, I'm not saying get rid of indexOf. I use it too. Keep it. But contains and methods like it would be a welcome method to me that I'd use every day. – 1.21 gigawatts Dec 24 '16 at 0:34
  • I like the idea of separate libraries but when they are core features that are part of a runtime or OS they are faster when they are implemented internally for the most part. As far as code bloat. I'm against it but I think it depends on what people need. It used to be you had 1024kb to work with. Now you 1000x that amount of space. If a core library is 500kb adding a few internal methods would add 12kb. That's not the same cost as it was 40 years ago. But if you add a high level function or library because it's not in core, it could end up adding 100-1000kb more to the application in the end. – 1.21 gigawatts Dec 24 '16 at 0:47
  • if a contains method is useful to you then fine, but if the method already implements a certain functionality that exists elsewhere and you can both with just a line of code than what's really the point? if you have a function that allows a 100 lines with just an invocation than yes, it would be something that may actually be needed. – svarog Dec 24 '16 at 7:40
  • 1
    in the long run you don't really want to have a bloated language with countless functions that do the same things similarly, you want language developers to add new stuff instead, new stuff, and less bloat. – svarog Dec 24 '16 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.