“Six programming languages ​​I want most!”

Translator | Meniscus

Produced | CSDN (ID: CSDNnews)

This article documents some of my personal thoughts on programming languages. I think these are all technically possible, and the reason they didn’t appear is just “not many people want it”. Maybe these functions already exist, after all I only know the language I have learned.

The first: contract-based languages

A contract is a predicate in your code, usually in the form of a function, and treated like any other assertion statement. An example of withdrawing money from a bank account is as follows:

 method withdraw(amnt: int) requires amnt <= self.balance ensures self.balance >= 0 { self.balance -= amnt; }

The Eiffel language used to be the standard contract language, but it has been abandoned since the mid-1990s. The only mainstream contract language right now is Clojure. Most languages ​​have contract libraries, that is, these languages ​​don’t use contracts very well. For example the following is_sorted(l) predicate:

 forall i, j in 0..len(l): i < j => l[i] <= l[j]

Most languages ​​have all and any functions, but don’t allow quantification over multiple elements, and basically no language supports implicit operators (since implicit operators are of little use in programming). I’d like to see a language that integrates contracts nicely into the grammar. At a minimum, preconditions, postconditions, and inline assertions should all have dedicated syntax. Also needed is the ability to mark and reuse predicates, as well as handle “orthogonal” predicates (only check the postfix of A if the predicate of A’ is true), etc.

And tool integration! A nice feature of Eiffel is the use of contracts to infer tests. If you have a contract, you can quickly generate integration tests with a fuzzer. Clojure’s Spec functions similarly.

The second: languages ​​that support semantic relations

Inheritance and interface are the relationship between classes. So what is the relationship between the functions? For example the following two functions:

 def window1(l, n): if len(l) < n: return [] out = [] for intervals in range(len(l) - (n - 1)): window = l[intervals:(intervals+n)] out.append(prod(window)) return out

 def window2(l, n): if len(l) < n: return [] out = [] val = prod(l[0:n]) for i in range(n, len(l)): out.append(val) val *= (l[i] / l[in]) out.append(val) return out

These two functions are used to compute the rolling product of the list l, so window1([1, 2, 3, 4, 5], 2) == [2, 6, 12, 20]. window2 is an optimized version of window1 and its output should be the same as window1 for each input. This should be reflected in the language, and the tool should be able to check that the output of the two functions is the same, and run a performance test to see if the optimized version is indeed faster.

I can think of other relationships as well. A’ is a measurable version of class A. g is an inverse function such that f(g(x)) == x. P’ is an orthogonal subtype of P, but not a Richter subtype. UML has relationships like “traces”, “refines”, “generalizes”, etc., so similar relationships can exist in programming languages. The point is, I want to be able to express these relationships at the language level so that programming languages ​​can take advantage of them.

These relationships can also be used for contracts, such as those used to preserve/convert/extend contracts. A very common one is “inherited methods have less strict preconditions and more strict postconditions”. What other relationship?

The third: everything is a picture

• Lisp: Everything is a list.

• Bash: everything is a string.

• Smalltalk: Everything is an object.

• APL: Everything is an array.

Graphs are a very common data structure, but no language is an “everything is a graph” language. In fact, almost no language’s standard library supports graphs! This is probably because a graph is a very complex data structure. Do you know how annoying linked lists can be? Graphs are 1000 times more troublesome than linked lists.

Still, I’d love to see someone try it out! For example, a key-value map is modeled with a directed graph.

Number Four: Better Computing Languages

I have a love-hate relationship with J. There’s a lot going on in the language itself that drives me crazy, but I still use it because it’s the only language that comes close to a desktop calculator. When I need to do a quick calculation in a project, I care about two things. First, the number of keystrokes. Here’s how to compute the product of factorials in Python:

 import math prod([math.factorial(x) for x in l])

Too much trouble! Very simple in J, just */ !l, an order of magnitude fewer keystrokes. Keystrokes are important when you need to experiment with formulas. But “everything is an array” in J language limits its potential as a calculator. It can’t handle strings, JSON, collections or hash tables very well, date operations are very cumbersome, and there is no way to deal with combination problems, wait. I wish there was a language for everything. It would be nice to also add namespaces to operators.

Another feature I wish the calculator had was built-in reactive programming, which is presumably a combination of a textual programming language and Excel. I would like to be able to achieve the following functionality:

 input = 1 out1: input + 1 #out1 is now 2 input = 4 #out1 is now 5 out2: out1.replace(+, -) #out2 is now 3 # let's pull an APL input = 4 2 #out1 is 5 3 #out2 is 3 1

Of course, it’s going to be very hard to learn, but I’ve gone on to learn many strange but powerful languages. Interactive computing is very common, and I learned a lot to do it.

…maybe I should use Excel at ease.

Fifth: Truly dynamically typed languages

(Some would say that Smalltalk is 100% dynamically typed language)

Static typing is great! There are a lot of cool things about statically typed languages, but not dynamically typed languages. Much research has gone into adding types to dynamically typed languages. I think dynamic typing itself has many interesting directions to try. For example, new types can be generated at runtime! Combining this functionality with contracts allows you to add constraints to variables such as:

 type Interval(x, y) <: Int { x <= self <= y; } var i: Interval(1, 10) = 3 i += 7 #ok i += 1 #error!

Cool, right? I don’t know if this feature is useful yet (maybe it’s just syntactic sugar for classes), but it’s still interesting. I want to see how people will use it.

I also want to be able to change the function definition at runtime. It seems to me like a nightmare to have a program that reads and runs other programs as input, and then I have to experiment with that program’s behavior under certain conditions. I want to be able to implement metaprogramming.

Sixth: Languages ​​that support the graphical interface as a primary function

I miss VB6 so much.

The text and pictures in this article are from CSDN