proj-plbook-plChImpMmOopLangs

Table of Contents for Programming Languages: a survey

Python

Because it is so well-known and well-liked, Python gets its own chapter.

See chapter on chapter on Python.

Go

Because it is so well-liked, Go (golang) gets its own chapter.

See chapter on chapter on Go.

Java

Because it is so well-known, Java gets its own chapter.

See chapter on Java.

Lua

Because it is so well-liked, Lua gets its own chapter.

See chapter on Lua.

PHP

Because it is so well-known, PHP gets its own chapter.

See chapter on chapter on PHP.

Javascript

Because it is so well-known, Javascript (js) gets its own chapter.

See chapter on chapter on Javascript.

Dart

A replacement for Javascript (ie meant to run clientside within websites).

Tutorials:

Overviews:

Features: method cascades, mixins, async/await, optional types, a rich core library, factory constructors, libraries, named parameters, lexical this, Futures, implicit interfaces, generics [1]

Opinions:

Implementations:

unsound type system in v1 but not in v2

" You can design a type system that's simple, sound, and expressive. But you only get to pick two of those adjectives. Today, because programmers are delightfully spoiled by a wealth of nice, expressive type systems, I think they won't settle for simple and sound.

Dart tried simple and expressive, but the lack of soundness made tooling much harder and really confused users who felt like they were being sufficiently penitent in their type annotations but still got punished for the sins of unsoundness anyway — type failures that were only caught at runtime.

So I think if you're designing a type system for a language today, you end up pushed pretty hard towards "sound + expressive", but now you're talking about a really complex beast. " -- [3]

my note:

Haxe

Compiles to Actionscript, Python, Javascript, Java, PHP, C++, C#, or Flash and Neko bytecode.

See also Haxe's open implementation of the Flash API: http://www.openfl.org/ (discussion of Haxe in that context: https://news.ycombinator.com/item?id=9655437 ).

Haxe Features

Haxe Tutorials and intros

Haxe opinions

Haxe opinionated comparisons

Have internals

C#

Because it is moderately well-known and moderately well-liked, C# (Csharp) gets its own chapter.

See chapter on chapter on C#.

Swift

Tutorials

Retrospectives

Swift Opinions

"Swift as a language is pretty great, however, the tooling and obj-c interop make it a pain in the ass....As well, it's far less 'scripty' than Obj-c. The type system in swift really leaves something to be desired in terms of typing types. The point of Obj-C was kind of to avoid writing the kinds of apps where a great type system would really shine, swift lets you build those kind of apps, but in my opinion most of the time we shouldn't be building them....ObjC? is a language that has everything you really really need, and left out the 1 thing you kinda wanted in exchange for leaving out the thousand 1 little things that everyone else wanted too. Like for example exceptions, sure they're there, but it's not idiomatic and when you program without them you realize what a crappy idea they were in practice. In day to day coding NSError is 1000x better than exceptions." -- https://news.ycombinator.com/item?id=9681090

"The problem I've found with Swift is the minute size of the standard library. This has forced a large amount of Swift libraries to make calls to Objective-C/Cocoa classes libraries which makes it very non-portable." -- https://news.ycombinator.com/item?id=9681408

That did not work well for me. I cannot make sense of a lot of stuff I have done in the past. Swift is getting too complex. It is a nice language but it is developing some of the same problems as C++ and Haskell ironically. The complexity and strictness of the type system is getting in your face a little bit too often.

It is a double edged sword. When I began using Swift I loved how the strong typing caught many mistakes. But it was always with a mixed feeling, as battling the type system was a regular occurrence. Now it seems to have gotten worse especially when dealing with closures." -- https://news.ycombinator.com/item?id=24043427

" ... why academics and data programmers are never going to use Swift:

Python:

  import time
  for it in range(15):
     start = time.time()

Swift:

  import Foundation
  for it in 0..<15 {
     let start = CFAbsoluteTimeGetCurrent()

This is why people like Python:

This is why academics and non-software engineers will never use Swift:

Swift gotchas

Swift internals and implementations

ABI:

https://download.swift.org/docs/assets/generics.pdf

Ruby

Retrospectives:

History:

" Ruby was conceived on February 24, 1993. In a 1999 post to the ruby-talk mailing list, Ruby author Yukihiro Matsumoto describes some of his early ideas about the language:[11]

    I was talking with my colleague about the possibility of an object-oriented scripting language. I knew Perl (Perl4, not Perl5), but I didn't like it really, because it had the smell of a toy language (it still has). The object-oriented language seemed very promising. I knew Python then. But I didn't like it, because I didn't think it was a true object-oriented language — OO features appeared to be add-on to the language. As a language maniac and OO fan for 15 years, I really wanted a genuine object-oriented, easy-to-use scripting language. I looked for but couldn't find one. So I decided to make it.

Matsumoto describes the design of Ruby as being like a simple Lisp language at its core, with an object system like that of Smalltalk, blocks inspired by higher-order functions, and practical utility like that of Perl.[12] " -- http://en.wikipedia.org/wiki/Ruby_%28programming_language%29#History

Tours and tutorials:

Respected exemplar code:

Gotchas:

Tools:

In-depth:

Internals:

Variants:

Ruby features

Ruby Opinions

" zem 1 day ago

yielding in a method without an explicit block parameter is actually my favourite design decision in all of ruby. it basically means every method gets a "free" optional block passable to it at call time, which in turn means that the language highly encourages (syntactically) code designs where a method implements some pattern and then yields to the calling code to fill in the details. compare ruby's "File#open" with common lisp's "with-open-file" - it was just the natural thing to do in ruby, versus having to implement something specifically for the open-file case in lisp.

reply

rat87 13 hours ago

I'm a guy who hasn't written that much ruby, I'm mostly writing python these days but I understand a lot of the concepts have written a bit of ruby and wish that some python things could be more like ruby.

Also I'm a guy who took a Smalltalk class taught by a passionate teacher back when I was getting my degree.

Smalltalk is one of the main parents of ruby. It's less practical then ruby in many ways but its more pure/simpler.

To me ruby's blocks/yield is one of the ugliest of parts of ruby. In Smalltalk just about everything is objects and messages. In Smalltalk Blocks are just special syntax for BlockClosure? objects that you evaluate by sending the 'value' method on them and they don't have to be passed at the end, you can pass multiple blocks(if you want ideas of why you might want to do this see some of the c# linq overloads: https://msdn.microsoft.com/en-us/library/system.collections.... (or some thread/future like thing with a run action and an exception callback) although I admit many of them can be done with an extra map function.

Ruby Blocks aren't objects, yield is not a method, it's harder to assign/store closure to variables and pass them around.

I may be wrong but I was under the impression that blocks are the way they are because they are a speed hack, the original ruby being a simple interpreter and blocks allowed the common pattern of defining and passing a closure to the method calling the closure without overhead of allocating/initializing/gc a block closure object.

Other objections ruby doesn't seem to be a language that the number of arguments in the function declaration doesn't bear resemblance to the number of arguments you can pass ala javascript I don't see why blocks should be special, I don't want to glance at the body of the function to see if it expects a block or not.

Also if you want to overload on block_given? you can use a named/default argument at the end defaulting to nil.

reply

masklinn 1 day ago

> it was just the natural thing to do in ruby, versus having to implement something specifically for the open-file case in lisp.

Uh what?

1. File#open is a special implementation, the canonical opening of a file is File#new

2. with-open-file is just a wrapper macro around unwind-protect/open/close

reply

zem 1 day ago

i meant that it's a natural thing to do in ruby to implement patterns like open/yield/close or decorate/sort/undecorate as methods that yield to a block. with-open-file was probably a bad example, but from experience it does change the feel of the language when you have to explicitly specify a closure argument versus when you just expect that your method should allow for a block to be attached to the method call. i'm not saying that these things aren't possible in other languages, just that ruby's "free" block makes them a culturally default thing to do.

reply "

" I think in hindsight it would have been helpful for Ruby if it had done something like square braces instead of brackets for hash literals, or not allowed brackets for blocks. The most ambiguous syntax all involves hash literals vs blocks… this adds to that cognitive load." -- [32]

Type system

Type annotations:

" This is anecdotal, but my experience was that Ruby was fashionable in the wrong kind of ways. For example... Ruby doesn't have primitive data types. Everything, including strings, are just objects. This level of purity is quite nice and "cleaner" in a conceptual sense. Until you encounter a large codebase with hundreds of monkey patches. Or, something I saw a lot, the extending of "base" data types such as String. I must admit that my memory is a little hazy here, but I remember that it was impossible to find language tooling that allowed me to "jump to definition" of anything I encountered. Ruby was so free-form with so much ambiguity that at the time it just didn't exist. I'm sure this has been resolved by now. In Python we had "Jedi" and other tools that worked really well for this purpose. You'd be browsing a Ruby codebase, see `some_str.foo`, and wonder: 1) Is foo a method or a property? In Ruby a function call doesn't need parenthesis if it takes no arguments. 2) Where is foo? I don't remember it being part of the standard library. Where is it defined? 3) If I do find foo, did something else monkey patch it? How would I know? 4) If I need to pass an argument into foo, should I factor it out of String? At what point am I overloading a base class like String with too much functionality? These are very real questions and the answers are important. Come across enough of these scenarios (remember this is just one example w/ Ruby) and you eventually give up trying to understand the codebase at that level. Everything becomes a black box, everything is magic. Do these footguns exist in Python? Sort of. You can't extend primitive types and monkey patching doesn't fit so cleanly into a normal program (think of it as "friction"). There was less ambiguity in Python's syntax. And the language community promoted a list of idioms which was helpful for discouraging bad practices. These things may seem subtle but they made a pretty big difference at the time. " -- [36]

Opinionated comparisons