Yee, or possibly brain cancer or something else undiagnosed. Syphillis wouldn't surprise me though.

I guess it's just something I have always heard. I have read supposed refutations of him having syphillis at all that argue in favor of brain cancer like you say, but I don't really know how to fact check it so I just stick to the meme fred rather than the real one.

Syphilis is probably the most commonly accepted running theory, but nobody really knows the true cause. Either way it matters what it did to him, not what it was.

If it was a tumah, and I'm going to spend some nice time pretending it was, I wonder what conversation his would have with the one that made Charles Whitman go all Charles Whitman. Different tumah personalities? Or just living in different neighborhoods?

It seems the older I get the less fluent I am in English. Approximately every decade I'm reminded of my failure to become fluent en Español. Now is one of those times.

I'm very surprised to see anyone take that position. I don't know much about language, but I have a hard time believing that a mishmash of Germanic and Latin languages with a huge number of exceptions and eccentricities would be in contention for best at anything. Intrinsically, anyway.



The funny thing is that the social sciences are where you REALLY need to understand statistics. The other fields are pretty elementary by comparison. Unfortunately, that cuts both ways, because that difficulty does make it inherently easier to pass off ideologically motivated or biased results.

English has a tight orthography, no diacritics, no ligatures (other than stylistic ones used by typefaces), trivial normalization rules, trivial lexicographic ordering rules, and words have a single canonical representation (modulo conversion to and from UK and American spelling, although nobody really expects software to do that).

As far as I know it's the only language in the family with these properties. Despite being a Germanic / Romantic mutt, those languages tend to be much more difficult to handle.

No kidding. Suck it, French.

Fun fact. Engineering students are not actually taught math. Instead, a smug professor wastes a lot of time showing off, and feeling smug about what a hard ass his program is, and the students sort of barely manage to scrape together a vague algorithmic understanding of what will be on the test. Because everything is covered so much faster than it would be in the math department, there's no opportunity for students to actually understand the underlying concepts to any meaningful degree. All the time is wasted by scrambling to sort of keep up. In the end, you actually learn more slowly, because the hastiness at the beginning means that no one can really grasp anything at the end. The tests cover content that is far simpler than what was technically covered in the course, and everyone still does terribly. Even if you worked hard enough to be one of the few students to get an A, you didn't necessarily learn very much. It's very hard. You just don't learn anything. The math department course I took for my Master's degree was both far easier than any of my engineering classes, and far more valuable.

From what I've seen, working engineers don't do much math either, besides manipulate algebraic equations. Most will see handwavey solutions to some PDEs and will know how to do some basic calculus, and the bright ones will know linear algebra, aka can use matrices and understand that a linear map from 3 dimensions onto 2 dimensions is not injective. But they hardly need to, say, solve a PDE when the mathematicians do it and give them a formula or algorithm.

Also yeah engineering profs can be smug.

What's really bad is when you have engineers or physicists teaching math at the lower division level at community colleges, who don't actually themselves know what math is all about, but are nevertheless keen to turn the class into a competition in order to command respect from their vulnerable students.

Of course a big part of this is surely due to the fact that most folks in those classes don't want to be there anyway (and consequently have a harder time realizing they are being cheated), except that either their college / major made them take it, or the subject demands knowledge of it as a service course (like engineering or physics).

It depends a lot on what you are doing. I'm getting a master's degree, because it's too easy to get thrown in the role of a glorified technician if you don't have one. There are a lot fewer roles where "real" engineering gets done, but those guys often do use math. Control Systems, RF, and DSP, for example, can get pretty hairy, but it depends on what level you are doing those things. Some guy fooling around with PLCs in an assembly plant probably won't see any math at all.

Back on the original subject of the thread, I can say with confidence, that after writing all of the code for my thesis project in C++, that I definitely do not know C++. In fact, I think I know C++ even less than I did when I started the project, which was not at all.

If you think you don't understand it, you probably understand it better than those who think they do. AFAIK C++ is less of a single language than a family of languages, so that different programmers may be writing code that is mutually unintelligible.

Of course Lisp is this way only infinitely so, but at least it is elegant in theory so long as the programmer doesn't go nuts creating DSL's up the wazoo.

I work on C++ development tools ¯\_(ツ)_/¯

Still know Korean, although it's hard for me to converse with native speakers. Oddly enough, it does well on Chinese gals.

But nothing makes me go soft faster than listening to spoken Chinese. I mean, it must be something with the tonal shifts or things of that sort with that language. It just kills the mood...

Is it worth it to pick up a functional language looking five years ahead, particularly Haskell? Trying to figure out which skills to hone.

In my experience technology choices are rarely rational, so if you're asking whether some specific functional language will be popular in 5 years, you probably aren't going to get a reasonable answer.

The only thing we know for sure is that today, eventually everybody rewrites in Java or C++.

Well, those are the languages I'm most familiar with, I suppose I could just.. stick with them.

A few things here.

First of all, if you want to get a job based on whatever programming language is trendy at the time, you're gonna be hard pressed to predict things five years out. Nobody would have predicted that Node.js would have become a hot thing to have on your resume, whereas plenty of web programmers already knew perfectly good languages like Ruby or Python or Java. Of course these are all object oriented languages, so in the end it is less the language itself that you can predict than the style if programming that can easily carry over to any new language you can pick up very quickly. In fact there are remarkably fee languages out there if you see them as no more than different dialects.

The functional paradigm is one that has become more and more popular lately, and you don't have to learn Haskell to take advantage of it. For example if you use R, you already have at your disposal idioms like map, filter, and reduce. Since functional programming is also largely about avoiding impure functions, you can code in a functional style (for example, there are now books on coding in functional JavaScript, and the language Clojure is basically a functional dialect (basically a Lisp) on top of the JVM).

You can even take advantage of the functional style of programming in very imperative, object oriented languages like C++, as John Carmack eloquently explained:



Full article: http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php

If you want to learn a canonical functional programming language that is also its own intellectually rewarding activity but as well transfers to practical skills, I recommend learning about the ML language, and using it do do things like write compilers or other such fancy things. Many of the top universities have settled in Ocaml as the language in which they teach their computer science courses: in particular, CMU, which is a top university in computer science, so do some searching on hacker news and Google to see links to old course materials on CMU.edu.

Haskell is fun for mathematicians to jack off to, and is a great little scripting language because it's so easy and fun to do powerful things, but the ML family of languages is based on a model of computation (strict and eager evaluation) that more closely matches computer hardware, and also doesn't suffer from the difficulty in reasoning about performance that a lazy language like Haskell does. Nowadays if you can get a job on wall St. at places like Jane St., you can use Ocaml there, and Microsoft has hugely boosted the popularity of the ML family of languages in industry by creating F#, which is a .NET language. On the JVM, an analogous language that gives you the power of the ML type system is Scala, although Scala is a multilaradigm language which also seeks to combine functional programming with object oriented programming (often with limited success in containing the complexity that results from giving the programmer so much power). Finally, Ocaml (and also Clojure) map very well to JavaScript, which means that if you learn to use Js_of_ocaml (or Clojurescript), you won't have to touch JavaScript again and be able to write nice clean code in a serious full feature language and still have it compile down to fast JavaScript.

Let's separate for a minute the problem of writing functional code for a practical purpose, and teaching yourself functional programming in principle. Java and C++ are very ugly languages for this purpose, and like I mentioned in my last post, top institutions like CMU have been using Ocaml for years. "A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis.

There are also other options if you are just doing stuff at home. Sure Haskell is one, but it can get way too clever for its own good real fast. I already mentioned the ML family of languages. But I shouldn't be remiss and fail to mention Scheme, which is pretty much the ultimate functional language in the sense that it is basically a Lisp that was designed to be functional from the ground up, and defined in a beautiful document by its very smart authors that describes the entire language and is updated every decade or so. Also, ML is very closely related to Scheme in terms of its execution model, but adds in a static type system, so your skills in Scheme can transfer to ML.

Oh, and by the way, Javascript (for all its warts and pathetic type system) is also based on Scheme. So if you know Scheme, you already understand what the functional bits of Javascript are.

The classic source for learning Scheme is the (in?)famous book affectionately known as SICP. Actually, Gerald Sussman is both a coauthor of the Scheme language itself, and of SICP. Of course, the book is a little strange, because, just like Michael Artin supposedly wrote his widely assigned Algebra book based on his course at that oh-so-legendary institution MIT for undergraduates who, being too junior to have actually learned linear algebra by their freshman year, nevertheless were being taught an abstract algebra course that covered linear algebra along the way, likewise, SICP is another creation of MIT pedagogy which assumes that the reader doesn't really know much about programming at all, but in doing so actually tries to teach the student more about writing very fancy things like meta-circular interpreters, generics, and compilers along the way.

Another cool book that teaches functional programming, but not using Scheme (the author uses mathematical notation and most of the code in the book corresponds to things from Common Lisp), is the book Functional Programming: Practice and Theory by Bruce J. Maclennan, which is pretty much as close as you are going to get in looking for a book about programming that also feels like math prose (and not computer science, where the metaphor the author usually assumes of the reader is some kind of mechanical automaton that enters commands into a machine without thinking) and also legitimately tells you WTF is going on (you get to learn about fancy things like fixed-point combinators and then seeing what they are practical for). For a modern take on Common Lisp, see the functional programming language Clojure, although Common Lisp itself in the form of sbcl and Emacs SLIME is an excellent development environment, so long as you assume that you will essentially never, ever use it in an industrial setting, because basically nobody does except as lone wolf programmers (although there is an active community which writes tons of code and there are plenty of libraries out there).

In fact, when you hear about things like map and reduce in functional programming, those actually are functions from Common Lisp. So even if you don't want to become a Common Lisp programmer, there are some rewards to learning it anyway.

For starters, you can read Paul Graham's "The Roots of Lisp", which is a great place to understand the reasons why Lisp is a historically important language, and in particular when it comes to functional programming.

Finally, if you are a fan of Socrates, you can also learn trivially learn Scheme in the form of a series of Socratic questions, by checking out the very whimsical but clever and short book The Little Schemer.

It's useful to note that functional languages are essentially just a particular class of declarative language where the basic object is defined recursively.

Lisp is a declarative language for linked lists.
ML is a declarative language for trees.
Haskell is a declarative language for... dependent types, maybe?

Like any other kind of declarative language, they are highly useful when your problem can be easily modelled within their designed framework, and exceptionally useless when it can't. As a consequence it is mostly important to learn these languages so you understand what they bring to the table, in case you encounter a situation where they might be useful.

And then you can implement that useful subset of the language in C++

And then do it over a cluster of machines at Google or Facebook and release it as the latest hot open source framework.

And actually I have noticed that even within explicitly functional programming languages, there are idioms that get recycled over the years. For example, in a interesting talk by Gerald Sussman titled "We Really Don't Know How to Compute!", from 2011, he said the following:



In this case Haskell is taking old idioms and making them more rigorous, with its fancier type system. This can either be a straight jacket or a blessing, and you'll get lots of strong opinions about the merits of types vs. their ergonomic cost.

Today I also saw the following remark quoted in a YouTube comment to a project (clasp) to bring Lisp macros to C++ using LLVM: "C++ templates are to Lisp macros as IRS forms are to poetry".

So on the one hand, Jon is of course right that declarative languages can very wildly between great and useless depending on the situation, but within functional programming, there can also big differences in how cleanly the same idioms can be expressed--sometimes they are well thought parts of the language design, other times they are bolted on much later, and yet other times they just end up being cumbersome to use in practice. (And yet other times there are things that feel fun and easy that blow up your program later on after it's deployed (hello C pointers). :P)

Another perspective to take, again from the point of view that there are different classes of programming languages, is to take the point of view of the kernel language. Prolog extraordinaire and educator Peter van Roy wrote a very well received book in 2004 called Concepts, Techniques, and Models of Computer Programming, which for many was seen as the 21st century update to SICP. Instead of beginning with a small functional language like Scheme and building up abstractions in the language itself, CTM has you learn a very flexible and general kernel language*, in which you can describe different language features on a meta level and which result in different paradigms of programming. The book tackles four fundamental paradigms, beginning with a declarative functional approach (Haskell-like), a message passing approach (Erlang-like), an object oriented approach (Java-like), and finally a relational approach (Prolog-like). In the intervening glue between these different chapters, van Roy explains how each of these paradigms handle things like concurrency in their own ways, emphasizing strengths and weaknesses in a language-neutral way. In fact, one of the more salient lessons in the last decade has been the limitation of the object-oriented programming approach to concurrency, and we have seen a shift away from object-oriented idioms and toward message passing and functional paradigms when it makes sense. If there ever is a significant shift to relational programming, the stuff van Roy wrote about Prolog should also be helpful.

If you don't want to read the book, van Roy has also summarized these main ideas in a paper:

Programming Paradigms for Dummies

If you try to understand this paper, you will get to keep your object-oriented skills, but also understand how they sit within the larger world of programming language paradigms.

It's interesting to note that the van Roy approach to things largely avoids the haranguing over types and mathematics that is characteristic of the older more functional programming based approach to pedagogy. In the past, most teaching material was centered around beginning with a functional core, and adding in types to clean up the code. van Roy instead focuses on the differences between language paradigms and largely avoids this by inventing this idea of a kernel language.

* The kernel language (version 1.4 is used in the book, not 2.0), by the way, is implemented in software. The software is called Mozart / Oz, and you can run it from Emacs to follow all the examples and exercises in the book.

The C++ I write these days is a lot more like C with Contracts than C with Classes.

That's interesting. C++ has come a really long way from cfront where it was just a preprocessor to cc and added in classes. Of courseit was Stroustrup who said, "Within C++, there is a much smaller and cleaner language struggling to get out".

I don't really write C++ myself, so I wonder if you often run into two things that seem to give C++ a bad rap:

1. recursive includes, and
2. out of control use of templates

...together, which I am told lead to:

1. very long compile times, and
2. extremely cryptic error messages

That's an involved subject and there's no brief way to address it without being flippant.

Maybe I can address them in order:

1. Recursive includes aren't a problem. Modern compilers have a lot of machinery to handle recursive includes as long as they are correctly guarded (either in the traditional way, or with pragma once). Unless you are doing something very specific and strange, a compiler will only preprocess each header file once.

The real problem is just includes in general. C and C++ translation units grow quadratically with respect to code base size. This size/compute growth happens regardless of how carefully you use headers, although you can manage it down by a constant factor with tooling and regular maintenance.

But yes, I encounter headers regularly because there is currently no alternative to them.

2. This is a subjective and vague statement. Is it specifically templates that are overused? Do constexprs, constexpr if, other kinds of static dispatch apply here too? If not, why not?

After pretty much any amount of scrutiny, complaints about template overuse really turn out to mean "I don't understand C++ and instead of writing C++ you should use the C-with-feature-X subset that I was forced to learn in my first job".

3. Very long compile times are a consequence of headers (quadratic TU growth) and using certain specific features (like SFINAE). The former, at least, should be addressed whenever Modules make it through the standardization committee (probably in 2023).

4. Cryptic error messages are a problem, but also really aren't one. It's usually very easy to find the original source of the error if you are a library consumer. The problem is, the compiler doesn't know if you're a library consumer or a library author, so it errs on the side of providing detailed diagnostics to all users, containing a detailed explanation for all of the candidate templates that were tried and why none of them worked.

This should be addressed whenever Concepts make it through the standardization committee (probably in 2026).

Thank you for not answering flippantly.

If I ever end up using C++ seriously it's good to have had these things cleared up, so thanks.

Russian, English, Hungarian.

When people hear me speak English they can't really place where I'm from, usually I'm told I've an Australian accent, but it's really a mix (British school on Cyprus, US school here, UK uni, Hungarian/Russian uni, etc.).

I mostly read in English these days though, and I actually write / spell better in English than in Russian because, well, I mostly work in English these days; but I think that's fixable, just have to read more.

I've a strong Russian accent when speaking Hungarian, though.