Hewlett Packard calculators use a proprietary language called RPL—Reverse Polish LISP. I found it very easy to learn, and I love it to death. Does that mean I can probably learn OOP without a lot of skull sweat? I read the wiki article on OOP this morning, and found it somewhat intimidating.
ANSI Common LISP is… well, not popular. Don’t expect to easily get a job if that’s the highlight of your resume. However, it is a very commercially viable language, it’s been used for plenty of big apps.
I mostly write graphical, numeric, and scientific computing libraries. I don’t really recommend Go for heavy scientific computing at this point, except maybe for bioinformatics or things that something like need parallelizable DSP, my work thus far is mostly bringing into existence a libraries to make Go more suitable for that.
I shouldn’t say that, Go is an excellent language for scientific computing in many ways. It compiles quickly, to native code, bypassing some of the issues with Python (even with Cython). It’s also a very conceptually simple language, with easy avenues to concurrency and parallelization. Its main downfall is some mildly obnoxious things (no operator overloading, so matrix math is all explicit function calls, a.Add(b) rather than a+b), and a lack of established libraries. If you’re willing to write stuff from scratch, I recommend it, unless maybe you’re switching from MATLAB or something.
If I didn’t use Go, I’d probably mostly use C; or maybe C++, but my C++ is mostly C with a much better standard library and classes. I also use Python a lot for numpy and its OpenCV bindings.
This is one of the things I love about Scala. For methods that take a single argument, the punctuation can be omitted (so “a.func(b)” can be written as “a func b”), and also methods can have names that are just strings of symbols (so you can name your method “+”). Operator overloading is just a special case of the general pattern.
Go actually intentionally didn’t have operator overloading. It’s not an oversight, it was an explicit design decision. They felt that it’s abused too often and makes code confusing, they did it to avoid
World - Rio // Nukes Brazil
sort of weirdness. I’m not sure I agree with the decision, but it was a deliberate one. In fact, they don’t even have function overloading/aliasing*. You can’t define Add(a,b int) and Add(a,b float32). You have to explicitly define AddInts(a,b int) and AddFloats(a,b float32).
- Technically you can overload, but only at the method receiver level. If you have two structs, A and B, you can define A.Add and B.Add, but you can’t have two A.Add functions that take different arguments.
Also, Go function names can accept any unicode character that’s NOT used elsewhere in the grammar. So you can have a function called 訳す that translates things to Japanese if you want, but not Trans()±**late.
Though Go has an idiosyncracy in the way it denotes visibility. In Go, there’s no public/private/protected keywords. It’s either public or private, and it’s all at the package level. A type, function, or variable starting with a character that’s considered uppercase by Unicode denotes that it can be seen and used outside the package (public), and one considered lowercase cannot be directly used outside the package (private). Go’s names are “exported” and “unexported”. The default is public, so CJK languages and such have a few issues making things private, the convention is to denote private things with the prefix “x”, so if you wanted your translate function to be private it would be x訳す. This is a decision I really like, it makes package visibility very clear just by looking at the variable name.
I haven’t heard too many positive things about Go from the programming languages people, and it seems like it’s having a little trouble gaining traction outside of Google. One of my favorite criticisms of any programming language ever is Go vs. Brand X, and I think it’s worth reading for anyone who’s seriously considering the language.
Not that many of his points don’t stand, but a lot of that code is syntactically invalid. Go doesn’t allow allman-style braces, and doesn’t have semicolons.
As for some of his lists of oversights, they’re currently considering a proposal for tables (mutli-dimensional slices). He mentions there aren’t many new features in Go, but… that was rather the point. I mean, you can be critical about that, it’s fair to miss various features.
But Go came about during the C++11 announcement, where they got fed up with all the new features and wanted to make a language that’s as simple as possible but still productive (they also wanted to reduce compile times as a major goal). They’re still “considering” things like generics or tables, but keeping it extremely sparse was deliberate. I mean, it’s not like they forgot constructors were a thing. They deliberately didn’t have classes, constructors, or guaranteed destruction.
Also, I think he’s missing the point on iota, the reason they chose that instead of enums is because you can do math with it. For bit masks, for instance
const (
NoFlag = 0
Tall = 1<<iota
Short
Long
Fat
)
Will be 0, 1, 2, 4, 8 etc. However, I definitely agree that not letting structs be constant is dumb.
I’m not sure what the issue about the cap function is, though, it lets you know how much you can grow your array until you have to realloc. It’s not used much, but it can be useful for memory pools. The main use of capacity is that you can deliberately overalloc an array so you can add to it later, but client functions only operate on the current data. You use the same trick in C all the time for knowing, e.g., a string’s length vs the size of the buffer it’s in. I’m pretty sure std::vector has something similar built in.
They also got the make/new distinction wrong. I’m not sure why they think you use “new” for custom types and “make” for builtin types. You can certainly do a := new(int), the resulting variable will be a pointer to an int slice. The make pseudofunction is used to preallocate slices and maps, and open new channels for concurrency. Also, new is basically never used. There are a couple of things that can’t be done as simply without the new keyword, but it’s there from back before make was invented and was left there for backwards compatibility.
I will grant that make is hacky. It’s a way of having generic containers without actually having generics. I’d prefer something else.
One heavy criticism I have of the Go developers though is that they have a much too stringent definition of “transparency”. Sometimes they’ll reject optimization ideas because it’s “non-obvious” that some code should run faster than others. There’s a thread on the mailing list right now about how copies of very large values shouldn’t actually copy if the compiler can prove the values never diverge. They seem to be hemming and hawing about how “minor changes to someone’s code could have extremely major non-obvious performance penalties.”
That’s… kind of the point of compiler optimizations though, to make code run faster with less effort on the programmer’s part.
Thank you! Way back in the day when C first started becoming popular, the criticism of the language was its lack of “features” compared to say, PL/I, et al. The best push back I heard to that argument was that, “its a tool to make tools”. Thirty plus years on I think that was a fairly good assessment.
Here is the article I was thinking of when I described how Go came about. It’s called “Less is Exponentially More”. It really shows the minimalist stance they take (sometimes for worse). I don’t agree with his analysis of type hierarchies, though. I mean, it would make sense if he was making a language that uses untyped lambda calculus, but Go is one of the strictest languages I’ve seen about types. You can’t even add an int and a uint without an explicit type conversion.
It’s a lot like Dijkstra’s quote on PL/I
Thank you Jragon for the cite’s.
Regarding, “… but Go is one of the strictest languages I’ve seen about types. You can’t even add an int and a uint without an explicit type conversion.”
I don’t have a problem with that. This is why I always linted my C code. Lint would catch that. As newer compilers came along, assuming you turned on all of the right switches, the compiler would too. Not all programmers are disciplined (or humble) enough to engage those switches.
ACK ACK on the Dijkstra quote. PL/I had to be one of the biggest languages ever. Only IBM could begat such a beast. I believe the selling point was that it gave you all of the record processing capability of Cobol with all of the precision of Fortran.
Different world.
I just learned that Ken Thompson and Rob Pike are involved at Google with the GO programming language. These two bring heavy weight to the table. I will definitely be checking out GO.
I always recommend beginners start with an easy language, like Agda, before moving on to more complex languages like C.
“The language has ordinary programming constructs such as data types, pattern matching, records, let expressions and modules, and a Haskell-like syntax. The system has an Emacs interface but can also be run in batch mode from the command line.” Agreed.
The very minimum set of features to get anything productive done. Add inductive data families, metavariables and synthesis through proof search, induction-recursion, coinduction and corecursion, definitional equality, and so on and then we’re really cooking with gas 
(More seriously, I’d probably recommend Python. I picked up enough Python in an afternoon to start being productive with the language, and Python has some incredible libraries covering virtually every task that you can conceive of.)
The ACM has just released a study which has Python overtaking Java as the first language of instruction in the top CS programs.
I think this is a good thing.
I wasn’t expecting that it would be a case of “oh I just forgot about that”. 
This was exactly the same reason cited as to why operator overloading was not put in Java – folks at the time thought it was frequently abused. And I agree that most of my colleagues who are so gung-ho about defining their own operators in C++ tend to be the kind of people I wouldn’t trust with that kind of power.
Scala tries to pull stuff in from the Haskell tradition, however, where naming a function “>>=” is not considered an abuse of anything. 
For those who may remember his Devil’s Advocate column in Unix Review and other notable writings, Stan Kelly-Bootle died. I had the privilege of Stan being the best man at my wedding.
"computer science n. [Origin: possibly Prof. P. B. Fellgett’s rhetorical question, "Is computer science? “] A study akin to numerology and astrology, but lacking the precision of the former and the success of the latter.”
A very sad day indeed.
Re: Banning operator overloading in Java.
I always thought this was one of many classic idiocies in Java.
Bad programmers are always going to do bad things. So what if a bad programmer might use “+” for matrix subtraction? The idjit could label the matrix subtraction routine “PolynomialDivision” just as easily. How do you go about preventing that?
Note that Gosling himself loved operator overloading. E.g., “+” for string concatenation.
Why hamper good programmers just because bad programmers exist?
I’ve written packages for algebraic entities in C++ and having operator overloading makes the code that uses these packages so incredibly more readable. Errors are a lot easier to spot.