Important languages to learn to understand different approaches and concepts
stackoverflow.com
stackoverflow.com
You program a bit differently when you have to wait minutes for it to compile in between tests.
He said he's familiar with the syntax, but that's only one piece (and often not the biggest piece).
[Edit: ouch, apparently I posted this with the last sentence unfinished! Also, I don't think the posted answer suggesting C or C++ is really talking about the same thing as I am.]
I also agree, knowing syntax is very different from working in the language at a production level for five years. Syntax, idiom, paradigm, and culture are all hugely important - some of those things are remarkably subtle for certain languages and only get picked up after being slapped by the more experienced programmers of that language!
Also, doing some simple circuit design might be fun. Simulators are available.
EDIT: Also forgot about to mention, but I find it odd that people still talk about learning a syntax. The OP mentions how he is familiar with the whitespace and C-like syntaxes as if that is the main point of the language.
I support C too. While I don't use it everyday (actually I avoid using it) I think it is important to do some low level and system programming - and C is here important. Every programmer should code e.g. a simple binary tree from scratch (with manual memory management) just to see what it is like.
Also as a matter of fact someone recommended C but it's buried down with 0 votes.
* Managing your own memory. If you want to build a distributed system, being able to fit more instances of your program onto a single box is going to save you a lot of money/headaches. Removing unused objects from memory is a valid optimization in most languages.
* Avoiding dynamic memory allocations. In languages like Python all memory allocation is dynamic. However, unloading/loading the same object over and over is something I've seen a lot of.
* Understanding pointer arithmetic and pointer passing usually leads to better understanding of how other languages pass data around. This leads to avoiding doing lots of copying of data structures in memory.
* More of a systems programming thing, but understanding temporary file systems, RAM disks, OS file caching and when to implement your own caching system.
* Better understanding of low-level concurrency implementations and its limitations. Most scripting languages have little support for concurrency (PHP has none, Perl and Python are pretty limited).
* Understanding of the stack and how expensive it is to make even a trivial call vs inlining code.
* Better understanding of network protocols, when to use TCP/IP vs UNIX sockets, how to arrange for connection pooling, etc.
* A general mindset of minimalism when it comes to allocating resources.
I don't think that C really teaches you to avoid dynamic allocation. In a lot of situations, it's unavoidable, especially if the program needs more memory allocated than the stack will allow.
What C teaches, as you said in the first point, is memory management. You don't use mallocs without knowing exactly when the memory is free'd, don't allocate new memory unless you actually need to, etc. C forces you to make decisions about how you're using the memory, whether you can stack allocate it, if it needs to be heap allocated, and when it needs to be destroyed.
"You seem to be a successful programmer, the rest is incremental. Not trying to be a dick, but ... how is your life finance-wise, relationships-wise, health-wise, fun-wise, hobby-wise? Perhaps now is the time to pursue some of those things."
I found the asker's response to be amazingly gracious. I would have been rather rude in return.
"Just got my hunter to 85, what class should I roll as an alt?" You seem to be a successful Hunter, the rest is incremental. Not trying to be a dick, but ... how is your life finance-wise, relationships-wise, health-wise, fun-wise, hobby-wise? Perhaps now is the time to pursue some of those things.
"just got a raise as a video technician, should i get my car fixed?"...
But I realized that one thing I would like is to one day experience mastery of a skill set. Success is not mastery, and there's no quick path there. I realized that maybe I'll spend less hours playing games, reading novels or just chilling, but I would like to one day have the life experience of having truly mastered a skill, and I think I would gladly give up a few side hobbies, video games, and great novels for that.
I think says it all
What does it say exactly? The only thing that I can think of is that it illustrates the point that there are some who seem to think they have a window into some else's life based on some trifle found on the Internet.You may be better served by _Essentials of Programming Languages_ (http://eopl3.com/), _Concepts, Techniques, and Models of Computer Programming_ (http://www.info.ucl.ac.be/~pvr/book.html), or _Programming Languages: Application and Interpretation_ (http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/) - also knows as EoPL, CTM, and PLAI, respectively.
It really helps to cover several styles of language with interpreters in one common language, to avoid getting hung up on syntax and other surface details. Anyone whose entire impression of Lisp / Python / Erlang / K consists of bitching about parenthesis / significant whitespace / "ugly syntax" / "unreadable noise" has cheated themselves.
Before reading the book, I was already pretty well versed in Haskell, having developed a bunch of moderately-sized and somewhat useful projects in it. So when I got to the Haskell chapter and realized that he leaves out one of the most important aspects of the language (monads get mentioned in passing and no more), it made me worry that he'd done the same in his treatment of the other languages in the book, and as a result I wasn't sure I was actually getting much useful knowledge about the languages from the book.
I admit that the task of teaching someone the "flavor" of a language in one chapter is a difficult (and possibly intractable) one. The danger is that if your summary ends up biasing someone against the language because of what you emphasized or what you left out, they might make an uninformed judgement about that language and as a result never pursue it further (or pursue it further only to realize that they probably shouldn't have bothered, though I think this is not as bad an outcome).
So, in the end, any opinion about a language I form as a result of reading the book isn't trustworthy. So... wouldn't I be better off spending my time learning languages from a more authoritative source?
Perhaps I'm worrying too much. After all, I might never have learned _anything_ about io if not for Seven Languages, and while a little knowledge is dangerous if used incorrectly, it seems like there's benefit in learning as long as I remain mindful of my ignorance.
My rant done, let me produce my list:
* Ancient Greek (or Latin) - inflectional: Just sheer coolness of it and the literature you can read in the original is enough. But these languages are the grand daddies of Indo-European (unless you wanna go Hittite or Lithuanian) grammar and will teach you valuable linguistic and conceptual points (i.e. cases, noun declension). Learning this is like learning ALGOL, kind of useless but you'll see where a lot of concepts have originated from.
* Mandarin (i.e. Chinese) - isolating: Two points: Seeing the syntaxlessness of these languages is mind boggling and expanding experience. Many poet/translators have remarked about the "timelessness" of Chinese poetry, because verbs don't have tense markings. And, of course, the writing system is very interesting, too. Like learning Lisp (Scheme), an interesting, expanding experience.
* Turkish - agglutinative: (Disclaimer, I'm a native speaker) A great into to the agglutinative aspect of languages (unless you want to learn an American-Indian language) and an interesting phonetic system, so regular, is used as an example a lot in phonology courses.
* Swahili: The concept of noun classes (a generalization of grammatical gender) is bewildering when you first encounter it, swahili has 16 of them (http://en.wikipedia.org/wiki/Swahili_language#Noun_classes)
And more esoteric ones that would be great to learn: My favorites would be Basque (interesting language isolate) and Georgian.
I'll also add Chinese's rather powerful "de" statement. It can be possessively and descriptively, but you'll often see whole sentences jammed up before a "de" in order to describe a single noun (or wildly recursive uses of "de"). About half the time I'm at a loss to translate sometime I find that I'm just not using "de" enough.
You can achieve the same effect in spoken English by speaking the jammed up portion quicker, and it's sometimes written with hyphens: "a (whole-sentence-jammed-up-before-a-de)-before-it noun."
I suppose it's a lot like the Blub Paradox. It's not that you can't do that sort of thing in English, it's just more painful.
To your list I would add Finnish or Hungarian for some hard-core agglutinative features. I don't speak Turkish, so I cannot tell to what extent it behaves similarly in this regard. See for example this list with 2253 forms of the word "shop" in Finnish: :) http://www.ling.helsinki.fi/~fkarlsso/genkau2.html
Then to cover some indoeuropean vocabulary, I would add one slavic, one germanic and one neolatin language for good measure, although this is a bit too eu-centric.
For some examples of what I mean by concepts that are sometimes difficult to translate, look at most examples on this blog: www.betterthanenglish.com/
The older examples are generally better, and I don't agree with the phrase "untranslatable word", but it should provide some general idea of the kinds of ambiguities that would be lost in translation.
You might get a scowl, or some other non-verbal feedback, during speech.
You can't translate poetry. Sure, you can find the equivalent words between the language in which the poem has been written and the language you want to translate into, but the original meaning is lost. I can give you countless examples, but the easiest it would be for you to pick a poems' book written in a foreign language (I assume you already know a foreign language) and read it in original. And then read the translation in your native tongue. They aren't quite the same, are they?
German as a second language was mandatory for all elementary pupils in fourth, fifth, and sixth grade in my childhood school district, very unusual for the United States. I had more German in junior high and senior high (in two different states) and then Russian in senior high. I entered university as a Russian major and immediately began taking Chinese, switching my major to Chinese as I grew in delight for that language. I have had formal instruction as an adult in Modern Standard Chinese (a.k.a. Mandarin), Cantonese, Biblical Hebrew, Literary Chinese, Attic Greek, Biblical Hebrew, Japanese (first in the medium of Chinese, then in English), Taiwanese, and Hakka, and various courses in linguistics (also in the mediums of both English and Chinese). I have engaged in self-study of Biblical Aramaic, Mongolian, Spanish, French, Latin, Hungarian, Malay-Indonesian, Esperanto, Interlingua, etc., etc., etc.
I have to respectfully disagree with the strong version of the linguistic relativity hypothesis. Within each language grouping, people differ far more in their personal thinking along the dimension of visual thinker or not, or auditory thinker or not, than people differ from one another in thought patterns based on language background. But it is useful to learn another language and to live in another culture for exposure to new basic assumptions, and the same applies to learning computer language paradigms. Besides the book mentioned in another reply, I like the books
http://www.amazon.com/Programming-Language-Pragmatics-Third-...
http://www.amazon.com/Essentials-Programming-Languages-Danie...
too as overviews of various programming languages.
I've studied Spanish (in highschool) and Japanese (for years) and while there were some new concepts (in grammar and sentence structure, mainly) they don't apply to anything but languages. And I'm not likely to try creating a language, and I've never had trouble expressing myself in the one I have.
What's the english word for 'schadenfreude'? or 'entrepreneur'?
After edit: the saying cherished by linguists in English is "'loanword' is a calque, and 'calque' is a loanword," which I find helpful for remembering which word is which.
Its not exactly uncommon for people to own businesses and to then employ people to run the company for them. This is pretty much how most long established public companies work.
That's a great line! I never heard it before.
Some governments actually try to restrict the usage of loan words and try to keep the language 'pure'. I think this is death for a language, and I'm glad English adopts new words so readily.
Someone recently told me that they thought that almost all the really interesting creative works were in English these days because English is so expressive, where many other languages have only 1 word for a thing. The language he used as a reference was Spanish, which he is fluent in. The word he used as an example was 'garbage'. He said in Spanish he had only ever used 1 word for it, but in English we have 'trash', 'junk', 'refuse', 'waste', etc, etc.
I don't know if that's really why, but it's an interesting thought.
The words 'trash', 'junk', 'refuse', 'waste' all carry different connotations. Be forewarned, my information is largely relative to Wisconsin. Other regions of the US may use the words differently.
If applied to a person: trash usually refers to someone that's disreputable in some grievous way, waste would refer to some that squandered some talent or resources. Junk wouldn't usually apply to a person but junkie means a drug addict. Applying refuse to a person would be silly, but probably be .
If applied to stuff that's thrown out: Trash is a generic term for anything that's thrown away. Waste is usually consider excess like banana peels. (waste and trash are largely interchangeable in conversation, the distinction isn't usually important) Junk would refer to material possessions that are no longer wanted like an old couch. No one would call banana peels junk. Refuse is a pretentious/higher class term for trash used by rich old ladies.
I don't believe refuse is in the common usage any more. I've never heard it used outside of Star Trek 6 and some older movies. It's meaning is similar to "trash" but it can also refer a place where trash is stored.
Most of english is this way. Words are extremely flexible and can be used in a variety of ways with many meanings. Context is extremely important. I'm not sure how other languages work, I only speak english.
In general, verbs in Spanish are way more expressive than in English: http://en.wikipedia.org/wiki/Spanish_verbs
Wish I knew more about linguistics - but I think missing tenses or grammatic logical structures are more interesting than missing vocab - like for example some languages have a tense for describing things you only know about second-hand http://en.wikipedia.org/wiki/Inferential_mood
(missed the bit I was meant to be replying to sorry...)
A thought experiment that I think works better is to imagine a language where people describe facial features extensively, to where a description in that language can easily be used to reconstruct an image of a person's face. Imagine how crippled a native speaker of that language would feel trying to speak in English, or the derision they would have towards the police sketch-artist process that took trained artists/interpreters quite a bit of time to extract a description from a witness that would sound like a 4 year old trying to describe a face. That's what linguistic differences are more like.
http://uva.onlinejudge.org/index.php?option=com_onlinejudge&...
(not sure if they are the ones from the book, but they are linked from there)
Also SQL! (although he probably knows it already...)
Also SQL! (although he probably
knows it already...)
That was my line of thinking in my reply. That's why I instead chose Datalog as the declarative choice. Much of what you can do in SQL can be done with Datalog (and vice-versa), but there are somethings that Datalog can do that SQL cannot.