4

In the making of a programming language, is it wrong to copy features and ideas from other programming languages? If it is not a problem, why not? Is it possible to license and copyright these things?

Abbafei
  • 821

7 Answers7

27

Is it "wrong"? In what sense could it possibly be wrong? Every programming language ever designed (except, I suppose, for the mythical Ur example) has borrowed concepts and designs from other languages. It's possible (and rather easy) to plot all extant languages on a family tree that shows their derivation. I can give you nearly endless examples of modern languages and the ideas they copied from older languages. Take the Simula -> Smalltalk -> Ruby lineage. Take the ML -> Caml -> OCaml lineage. I could go on and on.

As to your last question: you cannot copyright an idea. You cannot license an idea. Ideas are free in the truest sense (pathological US patent law notwithstanding).

The best languages available today are built on the best ideas of previous languages. Not only is it not "wrong", it's the best (only?) way to design a language.

As Newton famously uttered, we stand on the shoulders of giants.

Rein Henrichs
  • 13,172
3

Given C#'s similarity to Java, which was influenced by C++, which is an extension of C, which was derived from B, which was derived from BCPL, etc., etc., etc., I'd say the answer is "no". It's very rare to find a language that isn't influenced by or a direct extension of existing languages.

Language design is evolutionary; you take something which sort of works and try to improve on it.

John Bode
  • 10,856
2

I think the main decision point should be does the feature work well with the other features in the language and is it a feature you think the language should support.

An example would be Java where the design decision was made to exclude operator overriding from the language. Personally I am ambivalent about this decision, as I would love to have that feature available but I have also seen extremely bad examples of misuse.

A counter example would perhaps be the inclusion of "classes" in VB 4. They were not fully implemented or integrated and probably should not have been included.

PL/X as a language was extremely PL/1 like (funny that) but included many built in functions that were borrowed directly from assembler. It was also the only language I think of off the top of my head that had two versions of substring, one substring(start point, end point) and one substring(start point, number of characters). I realise that you can always derive one from the other but it was nice not to have to.

Michael Rutherfurd
  • 281
1

You mean, can you put an increment operator in your language even though it's already in C and C++ and Java? Yes, you can -- and obviously should.

Most language are very closely derived from antecedent languages (C comes from BCPL, C++ comes from C, Java comes from C++, and so on.) If you want to invent a language that is just like Java except that the switch statement doesn't fall through, go right ahead.

If I have seen a little further it is by standing on the shoulders of Giants. -- Isaac Newton

Michael Lorton
  • 445
  • 1
    I'm not sure that all languages require an increment operator :p Nice jab about Java's switch statement btw. – Rein Henrichs Apr 29 '11 at 02:34
  • Pascal based languages use the compiler magic Inc(i, n); instead. Unfortunately Inc is treated as a procedure (void) rather than a function, however the simpler for (for i := 0 to 9 do... construct makes this less necessary. – Gerry Apr 29 '11 at 03:02
  • Many languages treat integers as immutable, making "increment" or "decrement" operators impossible. Some languages treat all values as immutable. – Rein Henrichs Apr 29 '11 at 03:57
  • @ReinHenrichs -- integers are immutable. In a most languages, the variables that contain them are mutable (can be set to different integers). In a few languages, variables are immutable (or more strictly, there are no variables, only identifiers) -- Haskell and Clojure are two good examples. I'm not aware of any language where integer-typed identifiers are always immutable but other types are not. – Michael Lorton Apr 29 '11 at 04:02
  • i++ implies mutable integers as there's no assignment. I'm quite familiar with Haskell and Clojure. And Erlang. And APL. And J. And OCaml. And... – Rein Henrichs Apr 29 '11 at 04:10
  • 2
    @ReinHenrichs -- Are you under the impression that i=3;i++; would cause 3==4 to be true? If you are, you're nuts. If you aren't, but still think "integers are mutable" you have a tremendous conceptual lacuna around the difference between a variable and value, and reciting the names of programming languages isn't going to help. – Michael Lorton Apr 29 '11 at 04:17
  • No, I'm not under that impression. Nor do I fail to comprehend "mutable". Does "a" << "b" == "ab" imply "a" == "ab"? Nice use of "lacuna" (when you could have said "gap") in a vain attempt to make yourself sound smart though. Virtual +1 for that. Isn't this fun? – Rein Henrichs Apr 29 '11 at 04:24
  • In simpler terms: no, but it would cause 3++ == 4 to be true. Or, technically, ++3, as postfix increment would never obtain. – Rein Henrichs Apr 29 '11 at 04:25
  • @Rein Henrichs, honeybunch, I don't know what point you think you're making, but you're not making it. It's very simple, integers aren't mutable. 3 remains 3 for all eternity. In most languages, integer-typed variables -- hugely different things -- are mutable. I said "lacuna" because I meant "lacuna" and if you wish to discuss word-choice take it over to english.stackexchange.com . – Michael Lorton Apr 29 '11 at 04:30
  • "honeybunch"? Aren't you adorable. Of course (mathematical) integers aren't mutable. That has nothing to do with integers as implemented in programming languages (for instance, using registers that can be overwritten). In any event, we're probably violently agreeing. Snookums. – Rein Henrichs Apr 29 '11 at 04:37
  • @Rein Henrichs -- No, ++3 == 4 isn't true. It won't even compile, in C, C++, or Java. Try it, the compiler will tell you what I have been trying to tell you all night: required: variable, found: value – Michael Lorton Apr 29 '11 at 04:40
  • @Malvolio: Like I said: violently agreeing. Sweet pea. – Rein Henrichs Apr 29 '11 at 04:42
  • Dears, comments are not meant to be used for extended discussion, but for clarifying the question or answer. Please use chat for discussion, not comments. – Adam Lear Apr 29 '11 at 13:43
  • @Malvolio: Some early FORTRAN implementations used small integers by storing them someplace rather than just using them, for reasons that escape me just now. With procedures A(B) and C(D), you could call A(1), and A could call C(B), and C could have D = 2, and you've just changed 1 to 2. The last compiler I know of that did it was Microsoft's for the TRS-80. One person who encountered it solved it by assigning 1 to a variable and calling A with that, thus proving "Constants aren't and variables don't". – David Thornley Apr 29 '11 at 16:46
  • @DavidThornley -- yeah, I remember that. Wow, FORTRAN sucked; haven't seen it in 20 years easy and haven't missed it a bit. Strange how some really great, or at least interesting, languages were designed in the '60s (LISP, Pascal, APL), but the really awful ones got all the attention (FORTRAN, COBOL, BASIC). – Michael Lorton Apr 29 '11 at 16:52
  • @DavidThornley: I didn't think they did that so much with integers, but they often did it with floats. Floating-point numbers were (are) bigger than integers, and many instruction sets did not have instructions to load a floating-point constant into a register. Instead, a floating-point number would be included in a "constants" table, and code would load a value from its address. – supercat Mar 18 '14 at 23:57
1

Above answerers said enough about copying. Though my suggestion would be, don't copy features just because 'Java has it'. Think about programmers who will write in that program. Would you use that new language for production work?

To comments about software patents: In the US and in countries where software patents are legal, you CAN patent an idea (for example, RIM was not allowed to use WiFi to transfer e-mails).

I agree that's an absurd, WiFi is only a internet connection type, and patenting Wireless E-Mail delivery is the same as patenting E-Mail delivery itself.

It's highly likely for the US Supreme Court not to allow litigating software patenting cases anymore, but time will show us.

Luka Ramishvili
  • 111
  • A patent is very different from a copyright. You have to apply for it for one thing, you have to pay (a lot) for it, and it's a lot weaker. It has a short lifespan, and violating a patent is only a tort, it can never be a crime, so the FBI won't help with a "crackdown". – Michael Lorton Apr 29 '11 at 16:55
  • Yep. But the only way to lock an idea to you (at least in countries with software patents) is to patent it, though I am strongly opposed to this practice and strongly discourage it. – Luka Ramishvili May 01 '11 at 06:53
0

Copyrighting algorithms and code in general tends to be a very sore subject in the SE world. The idea is that if you come up with a way to solve problem X, you shouldn't be prevented from solving that problem just because someone previously used a similar approach.

If you did allow copyrighting of language features where would the line be drawn? (e.g. Can the first language that came up with the idea of arrays claim ownership over any future reimplementation?) It has the potential to be a very ugly mess if allowed.

I think at the basic level the question really doesn't fit the subject. Languages are not typically created with the intention to market and license the use of the language.

Jeff Swensen
  • 356
  • 1
    Copyrighting algorithms is not a sore subject. It don't exist. You can't copyright an algorithm. You can try to patent it, it's legally permitted, but don't hold your breath. – Michael Lorton Apr 29 '11 at 02:20
  • You only copyright source code -- an expression of an algorithm. – S.Lott Apr 29 '11 at 02:24
  • As S.Lott said, the only thing that is copyrightable is the material expression of an idea. You can't copyright algorithms (or other ideas). And thank goodness for that. – Rein Henrichs Apr 29 '11 at 02:36
  • It's possible to patent algorithms in the US (well, technically you don't patent the algorithm itself, but you can set it up so any use of the algorithm is an infringement). Most people in the software circles I frequent strongly dislike this. – David Thornley Apr 29 '11 at 16:48
0

You should copy the ideas. However, you should only copy the ones that seem good and won't make your language inconsistent.

The side note: another programming language? Hm... Maybe I should invent one (or two) ;)

Paweł Dyda
  • 1,508