Comment by Locke1689 | Hacker News Reader

Comment by Locke1689 | Hacker News Reader

Parent Full thread

No. You learn by doing. You write some stuff, test it, and if you don't get the result you expect go back to try and figure out what's wrong.

No. This is how you learn to do whatever simple things you want in a language. The way you learn how to do things correctly is mainly by reading code. If you have an expert to review your code that's better, but almost no one has that opportunity.

Edit:

I guess I should come right out and say what I'm thinking: not everyone's opinions about a programming language are equal. I suppose this is why people are constantly having discussions about the pluses and minuses of "dynamically typed" languages, while type theorists don't even recognize "dynamic typing" as a form of typing. Expert analysis has consistently shown problems with the R language design and implementation. It's not a good language. Its features are often misused or poorly used and it doesn't have a strong sense of what support it wants to give to its users.

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Why...

http://www.cs.purdue.edu/homes/jv/pubs/ecoop12.pdf

R works really remarkably well and clearly for folks who work in this domain day to day. It's easier to learn than a lot of other languages for people who are coming from subject knowledge and need to program to implement that knowledge.

It may be a terrible language by some objective external computer science criteria. But as a domain specific language, that's not really important. What is important is that the domain specific aspect works well for people with domain knowledge.

It's not the right tool for every job or every person, but it's incredibly expressive for people working with a specific set of problems.

What you're talking about is the environment. R seems to have a very nice environment -- a lot of people have written libraries for it and it is popular among the community.

I was quite clearly criticizing the language, which is bad. That doesn't mean you shouldn't use it if it's the best option for your use case, just that it's bad.

I've been interested in type theory for a while, but haven't found a good avenue for getting into it.

Could people here list any resources on type theory that comes to there mind? Books, blogs, people, etc. A book that explains the fundamentals would be great.

http://www.cis.upenn.edu/~bcpierce/tapl/index.html

http://www.cis.upenn.edu/~bcpierce/attapl/index.html

While not being exactly about type theory like Pierce books (you can't waste your money on those), I really like the part about types in "The Implementation of Functional Programming Languages" by Peyton Jones (the chapters about type system are written by Peter Hancock). It's seen mostly from a technical point of view. The book notably contains a fully explained implementation of a type checker.

You can check it online while waiting for the Pierson ones: http://research.microsoft.com/en-us/um/people/simonpj/papers...

By "can't waste your money" do you mean that buying them is not a waste of money or that I shouldn't waste my money on them?

Also, thanks for the link to the article.

Sorry for the ambiguity. It's certainly not a waste of money. I found "Types and Programming Languages" really good (for whatever that means, I'm far from being an authority in the subject). It seems to be wildly used as a textbook and is a reference in the subject. While I didn't read it, I expect the second one to be in the same vein.

The second link is relevant but only speaks to the performance of the language, which is something fixable in the implementation. Personally, I think the R language is pretty nice, and well suited to its domain. It has first-class functions and first-class environments, and an object system inspired by common lisp and Dylan. While not homoiconic, it's pretty easy to compute on the language. Statistically, having support for missing values built in at a very low level is important.

But maybe you just don't like "dynamically typed" languages?

Please reread the paper. It contains many things about the language semantics, e.g.

As for sharing, the semantics cleary demonstrates that R prevents sharing by performing copies at assignments. The R implementation uses copy-on-write to reduce the number of copies. With superassignment, environments can be used as shared mutable data structures. The way assignment into vectors preserves the pass-by-value semantics is rather unusual and, from personal experience, it is unclear if programmers understand the feature

And no, I did my master's thesis in Racket. I'm fine with unityped languages, I just describe them properly.

That's a consequence of having first class environments - but given that it's rarely used, shouldn't a sufficiently intelligent compiler be able to optimise it away in the common case? I'm sure I read a paper along those lines, but I can't find it again.

On a related note, have you read the riposte paper? http://www.justintalbot.com/wp-content/uploads/2012/10/pact0...

"sufficiently intelligent compiler"

;)

But seriously, every under-used feature harbors a ton of bugs in the compiler and drains resources for implementation. Promises, for example, seem like a "feature" in R that only really serves to destroy performance and no one uses it.

Agreed, but it's hard to know in advance what features will be useful, and once a language is established, it's hard to remove less-used features without breaking existing code.

How do type theorists distinguish Forth from PHP from Haskell without recognizing "dynamic typing" as a concept?

Haskell is typed. The rest are not (or unityped if you're Harper).

They do, parent was just wrong, and ignoring the fact that people use "language" colloquially to include the operational semantics, and pretending that only denotational semantics exist.

Dynamically typed languages have a typed runtime, do not a type in the static program text. Hence the commonly used correct qualifiere: "dynamic" and "static".

http://research.microsoft.com/apps/pubs/default.aspx?id=6752...

Please read TAPL again.

A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.

The word “static” is sometimes added explicitly--we speak of a “statically typed programming language,” for example--to distinguish the sorts of compile-time analyses we are considering here from the dynamic or latent typing found in languages such as Scheme (Sussman and Steele, 1975; Kelsey, Clinger, and Rees, 1998; Dybvig, 1996), where run-time type tags are used to distinguish diﬀerent kinds of structures in the heap. Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard.

Perhaps I should have been more clear that we use the words "dynamically typed" because they have entered the lexicon, but they are misnomers -- they do not properly capture what type theorists mean when they say "type".

Reply on news.ycombinator.com