Based on the code snippet, I'm not surprised he thinks C# is "verbose" with "lots of boilerplate" and "resembles Java", because the snippet is written as if it WAS Java, or at least written 10 years ago. Compare his GetFrequencies implementation with idiomatic, LINQ version: http://pastie.org/8834650
I'm someone who has put lots of C# into production and whilst you're right, caution has to be used when using LINQ. There are several humungous hand grenades that will go off in production unless you really 100% understand how it works (memory ballooning, infinite sequences, total misunderstanding of log complexity, leaky abstractions and difficulty of debugging).
LINQ is a tool, and a great one. But just as you need to understand malloc when writing C, you need to understand the basics of LINQ to use it in production. The main problems I've come across are all failure to understand delayed evaluation. Maybe I'm not using it in a complex way, but as soon as it start to feel too complex, LINQ is not the way to go.
I agree that it can be difficult to debug - that's why it should be kept simple. Personally, I love that LINQ enables me to think of my data in terms of sets and operations on them, rather how to execute the operations on the data.
It should be used with caution and not abused, you're right of course.
But when I use LINQ's GroupBy, SelectMany etc. I know they've been tested millions of times before.
The same cannot be said about somebody's "hand-made" algorithm, accomplishing the same result with foreach loops, breaks etc. like you would in good ol' Java.
So it's not just a matter of being imperative, long-winded or ugly.
You can also break LINQ expressions down into a series of simplier ones: deferred evaluation is a bliss here!
Or - thanks to the way it works, extension methods, anonymous methods etc. - simplify it by creating your own LINQ-like functionality, such as - say - Batch (not part of the standard Linq library)
What are the best resources for really grokking LINQ in depth? I'm not too impressed with the level of depth in the main LINQ section on MSDN - it seems (sensibly) more focused on how to use it than on how it works.
The biggest thing for me with grokking LINQ was understanding the difference between IQueryable and IEnumerable types of operations. Most of the complexity in the runtime with it is with IQueryable. I don't know if there are a lot more resources out there but the best one for me was understanding Expressions and that namespace in .Net and trying to grok the ASTs that were being passed around to understand how it was all working.
There are a couple smaller LINQ implementations out there like Linq to Amazon that you can take a look at (Linq2<insert whatever here> libraries seemed to be coming out of nowhere for a while).
This seems to be popular (a lot of people had it at the MS shop I interned last year) [0] and, to be daft, here's two more recommendations via SO/reddit: [1] [2].
I completely agree.
After having used C# extensively recently, and having used quite a lot of Java before that, I have a feeling that C# is what Java should have been/should be.
LINQ alone makes C# infinitely less verbose and 'boilerplate' than Java.
Given the large surface areas of each, I'd be astounded if there were zero points on which Java is genuinely superior. I don't recall either well enough to give any specifics.
Viable production-ready implementations existing on all major server platforms (without having to jettison favorite libraries here and there), is a pretty big one, but I guess that might go without saying (or maybe outside the scope of "language" proper - but that's the elephant in the room).
While it's a pretty impressive survey in its breadth, he doesn't seem to have much depth in a lot of the languages. There were mildly cringeworthy things in all the sections for languages I know well. For instance, the Ruby section seemed strangely obsessed with Rails, saying that programmers find joy in Ruby, citing the metasploit folks as an example, and then confusingly attributing that joy in part to Rails, which of course metasploit doesn't use.
I know nothing about C#, but I keep hearing announements of Groovy-like features in C#, and to me, Groovy is what Java should be (but with better performance). If C# is really like Groovy with better performance, then it should be a very nice language indeed.
I've tinkered with Groovy (writing custom event handlers etc for Jira). If I was going to spend any serious time writing stuff to run on the JVM then Groovy would probably be my choice. C# has been my primary development language since 2002. Fell out of love with it for a while until LINQ and then dynamics appeared. Oddly, this week I am writing nagios plugin code in Perl, which I am getting a weird kick out of, I haven't used Perl in anger since 1999.
If you have a more recent Perl available, use it and it's newer features (use 5.014; at least, hopefully). It's a small thing, but being able to call keys/values/shift/unshift/push/pop on the reference versions of their subject is very nice. There's useful new features in every new version now.
Additionally, Function::Parameters (or some other module that does similar, take your pick) will make your life much, much simpler if you tend to write a lot of subs.
Use Moose (or at least Moo or Mouse, if you want it lighter weight) if you are using objects.
> I keep hearing announements of Groovy-like features in C#
I'm pretty sure the builders of C# didn't think about Groovy at all when putting in features such as closures and dynamics. Correlation doesn't imply causation.
Well, those features. Groovy was probably one of the first to bring those to a C-type language (though you could argue whether it's still a C-type language with those features), but I'm glad to see them in more languages.
+1 This. C# counter-example: NancyFx. A library that enables you to write a complete Web Server in a custom DSL that (if written correctly, of course) reads as close to English as you can imagine. Plus Type Safety. Plus awesome SQL Server Support.
P.S. The other reason you use C#: you want to interact w/ SQL Server. TDS works, but boy is it a pain compared to just adding a reference in Visual studio. Also the bindings for TDS are pretty weak in some languages.
If you wanted to make a version with a live UI that's monitoring a stream instead of a file, I suggest Reactive Extensions. It adds support for IObservable, the stream version of IEnumerable (what LINQ is used against). Once you get your head around it, there is magic to be made. I think a bunch of Reactive Extensions is now bundled with .Net. It is produced by Microsoft.
Some nice angles in the article, but now I feel obliged to defend C++ (and actually C# and F# too, but I'll let that to others as I'm sure it will turn up in the HN comments) since the author seems to make no real points to support his view of it as a monster.
First of all, it's not because x [1] and y and a bunch of others say that "a == true", you can safely use it as a fact or a way to support your view (those logical fallacies are called Bandwagon Fallacy/Appeal to Authority).
Second: I don't know where those code samples come from, but that is not exactly how you write good C++, as it is called in the paragraph. And a paragraph lower there is mention of the dreaded C/C++ - a thing that does not exist, never has, and never will. Some might say that adds to the author's points (as in, it's so hard he doesn't know how to write it properly), but you might as well say: sorry, but if you don't know how to write it properly then you do not really have the bagage needed to start criticizing it let alone calling it a monster.
[1] esecially when x is called Linus and he's in one of his rage moments where every single being that does not think alike is violently insulted and reduced to the dirt of the earth, with or without arguments making sense :]
> Some nice angles in the article, but now I feel obliged to defend C++ (and actually C# and F# too, but I'll let that to others as I'm sure it will turn up in the HN comments) since the author seems to make no real points to support his view of it as a monster.
C++ is incredibly popular, the term "C++" is even known among some non-programmers. This might partially explain why it gets a lot of flack .... oh, that reminds me:
i guess maybe now is a good time to repeat this request - does anyone know of a good, recent book that describes how to write correct, modern c++ using the latest standards and staying with the subset of the language that expert users recognise as elegant and powerful?
I think I have an older edition of that book, and it doesn't cover recursion. I would not recommend it for a novice programmer, other than picking up basic syntax, since it doesn't give anything substantial to sink your teeth into.
The last C++ text that I came across was "C++ In Action: Industrial Strength Programming" by Bartosz Milewski. It was first published over a dozen years ago, so it will have dated a bit. In the first chapter the author explains objects using the usual taxonomist analogy, but also explains it in terms of the concept of scope. That first chapter alone gave me more insight than most of the SAMS text.
> I don't think that recursion is really idiomatic in C++.
Ok, I think you could throw that at C as well. As a general programming concept it's quite idiomatic. All I know is that fucking up recursion is just as easy as fucking up iteration.
Well it's not really idiomatic in C either. And it's not about fucking it up but about performance. Even if you do tail recursion, it will still be slower.
Well isn't that a cute dilemma. You're either an idiot, which means you won't understand it and shouldn't criticize, or you're not an idiot and your lack of understanding is an effective criticism.
Reminds me of Haskell.
Personally, I'm of the view that the planet is populated by humans, and you have to work with them, and C++'s arcane tome of a standard is perhaps a hostile environment for such creatures.
>Personally, I'm of the view that the planet is populated by humans, and you have to work with them, and C++'s arcane tome of a standard is perhaps a hostile environment for such creatures.
I don't know, everybody who's doing serious commercial programming seems to doing OK with C++, for stuff from Photoshop to Premiere, and from MS Office to AAA games and super stable and fast multimedia apps, like Cubase, Studio One, Reason et al.
In fact, OSes aside, more programs of this kind (full featured applications used by billions of people) are written in C++ than in any other language, including C.
>Really, so anyone using a higher level language for line of business apps isn't doing serious commercial programming?
Well, IMNSHO business apps (I take it you mean "enterprise apps") are not the epitome of programming, much less serious programming. Especially in-house apps.
But it should be obvious from my description that with "commercial programming" I meant the end user market, and things people used to buy in a box or (now) download to run on their Desktop. Not, say, some IBM Java based toolset for the enterprise.
So stuff like MS Office (or LibreOffice), multimedia apps such as Premiere, Photoshop, Avid, Cubase, all modern browsers, AAA games, etc etc.
> business apps (I take it you mean "enterprise apps") are not the epitome of programming, much less serious programming.
I'd reverse that and say the polished, packaged apps are the exceptions, these days. Code behind webservers and business backend processing is the code that runs the world now. To see C++ used in such code is pretty unusual. I do think C++ has its place: kernels, drivers, numerics. Not much else.
I love how F# is among the "unreasonable languages". Why? Because it's "Microsoft trying to be cool", "many of us have learned to keep away from Microsoft the hard way" and "we have enough company-sponsored languages already". That's it.
«The first true object-oriented language. But it seems to me Smalltalk is pretty much a forgotten language.»
Why do so many people kill Smalltalk so fast?
I could give so many URLs to illustrate how Smalltalk has a stable and growing community, with so many open projects and people making a living out of it, teaching it in universities and using it for research, but I think these two links sum it all up:
Well, just from my noob point of view, every time I've dug in and tried to get into Smalltalk, I've found the language to be really really nice, but I've found the ecosystem to be really really confusing. The concept of needing a development environment and a persistent image (probably not even using the right terms...) just doesn't click with me. I struggle to figure out where to put things, or how to use my editor, or how to use source control, or how to distribute my programs, and maybe some other things I'm forgetting.
I'm sure there are mind-expanding answers to all these questions, and I remain open to learning, but I wanted to give a counterpoint to the frustratingly inane "har har curly braces" sibling comment. Sounds like Pharo is nice (but that's what I heard about Squeak before...).
Sounds like you are not "ready" for Pharo yet. The problem with Pharo is that, as I said in the comment below, it's all in one package - it has built-in editor, built-in version control and package system, file manager, and generally built-in tools for almost everything. Image-basedness is also a big difference, it's a powerful concept, but it can be hard to really grok and use it effectively.
From what I know I think there are two ways you could go to avoid all this problems until you feel comfortable enough with Smalltalk to tackle them again. One way is GNU Smalltalk, "a Smalltalk for people who can type", which feels fairly normal to work with. You can use your editor and version control software with ease. From the look of it it has a bit less libraries and a bit smaller ecosystem and community, but it could serve you well as introductory Smalltalk.
The other way is Amber, which is a Smalltalk written in JavaScript (or maybe it self-compiles already?). It comes with a "browser" (the thing you use to explore and write code in Smalltalk) implemented as a JS app and you can play with it immediately in your (web) browser. It's also half-image, half-file based, so while it will introduce you to the concept of image based environment, you will use your favourite editor and other tools.
Smalltalk can feel very confusing at first and it is really different from what you know already. It may not be always possible to learn all of Smalltalk system (like Pharo) in one go, especially if you're working and you don't have too much free time. Going through the stages, from less-smalltalky to full Smalltalk environment may take a bit longer, but it will make it easier to learn it.
Getting back to the thread-starter: Why do so many people kill Smalltalk so fast? After reading your comment, my answer to that question is: because doing it The Right Way entails learning a lot more than just the programming language itself, and it isn't clear (to me) what motivates those things.
+1 for this - Pharo is my platform of choice for developing hobby projects and I'm really pleased with it. And it moves really fast, with 3.0 release scheduled this month (IIRC) and with very exciting features planned for 4.0 too.
I checked out some other Smalltalks, including the GNU and VisualWorks ones, but Pharo comes as the cleanest all-in-one Smalltalk starter kit.
On a related note, I recently started playing with Io, which is very interesting too. It's smaller than Pharo and not image based, which makes it better suited for scripting (although it's possible to run Pharo in headless mode), has easily modifiable syntax and is pure object oriented with prototypal inheritance. If you like Smalltalk give Io a shot, chances are you'll like it too.
Because it doesn't have curly braces. Entirely unfair, but it seems like if you want to sneak in an innovative language it needs to be a wolf in sheep's clothes. (IE: it need to vaguely resemble C)
I think both are true, because "the community" is not one thing. It's a bunch of people, each with their own viewpoint. And a bunch of people have strongly-held views (in both directions) on curly braces.
That's one of the big reasons why javascript is so horrible. It is a really nice and innovative language, but it had to be dressed up to resemble C (or Java really).
I'm going to hazard a guess that the problem is not the physical keyboard, but rather the OP's use of a non-US keyboard layout. My native portuguese keyboard layout uses AltGr-8 and AltGr-9 for square brackets, and 7/0 for curly braces, and it's incredibly uncomfortable. I eventually changed to using the US International layout (with dead keys) to make it less awkward to write code, to the detriment of writing in portuguese.
> First of all, a disclaimer: unless you’ve developed in 30+ languages, and suffered the code of others in all (or most) of them, you can’t really be objective. So yes, I’m biased. Like most of the people writing about this topic. Actually, I believe that this topic becomes absurd as soon as you are well-versed in many languages.
I fully agree with this sentiment and I wish more people either already had 30+ languages experience or at least realized that most of what they say now will sound stupid to them once they got this experience.
After years in the C++ swamp, programming Lua feels like being a world-class sprinter. Sure, there are places where it could be less verbose (the 'function' keyword, if-then-end), but overall it's liberating to have so much power with so little typing.
Ok, it's a visceral (not technical) impression, but there's plenty of places to read about Lua online. I highly recommend giving it a try.
Agreed. It's not as terse as something like Python, but it's pretty speedy and generally a pleasure to program in. (I'd get headaches if I had to look at Objective C blocks all day.) On the other hand, the availability of pure Lua libraries and even the official documentation aren't as complete as they could be.
Red Hat .. somewhat kicking and screaming, but we've shipped the OCaml compiler, libraries and programs written in OCaml since RHEL 6 (note that Red Hat does not support the OCaml compiler, although there are customers that use it).
Edit: The chances are if you used a program that started with virt- on any Linux distro, then 50/50 OCaml was involved in the making of that program. It was either written in OCaml or used OCaml to generate large amounts of C boilerplate.
OCaml binaries look a lot like C binaries, so it's hard to tell from the binary. And it turns out that functional languages with pattern matching on data are extremely good for generating all that C boilerplate, like crap you need to write for FFIs or dealing with remote parameter marshalling.
Have you ever seem a simple Prolog program solving the 'four coloring problem'? Try programming that in anything else. Prolog or something similar like Lisp with pattern matching is the tool of choice for speech recognition programs. Why these tools get dismissed in a world of tablet devices using Siri or Google is beyond me.
The computation model of Prolog is fairly simple, relies on few primitive, and could be reimplemented in many language without much hassle. The abstract interpreter fits on a 1/4 page.
With unification and backtracking, you're into nondeterministic programming. It's great for some problem, and I agree it should perhaps be more regarded than it is, but it can be emulated inside other languages to solve such problems. You also have to be quite careful when using non-determinism.
That being said, my main point is that I think the "simple Prolog program solving" X is misleading. Of course a solution to a problem that requires exactly the model of computation the language provides is going to be simple in that language. But that model of computation isn't exclusive to that language, and I don't feel the implementation of the model in other languages suffer.
I think prolog gets a bad rap because people don't spend the time to learn how it really works and how awesome it really is. More than matching which you can get in most functional languages, non-determinism from prolog makes solving all kinds of problems (four coloring included) elegant and simple. If prolog had more of a community behind it, I think it would move up that list pretty quickly.
It's a bit sad that we keep reading these articles and keep falling into the same trap of rush-to-defend-your-favorite-language and rush-to-complain-that-your-favorite-language-was-omitted. I find these articles seldom thought-provoking and the comments they inspire even less so. It's like reading "10 best ski runs in the country" or something. It's entirely subjective and hardly anyone will agree for any decent set of reasons.
No Groovy? If you want to address which is the best JVM language, you've got to at least mention Groovy. Its advantages include being trivial to learn for the vast hordes of Java developers, while making programming a lot more fun in a Ruby-like way.
When to use it? When you want the JVM, and productivity is a bigger concern than performance.
> If you want to address which is the best JVM language, you've got to at least mention Groovy
You could make that argument for all of the many ecosystems mentioned in the article, e.g. because for Unix/Linux scripting only bash is mentioned, you could have opined "If you want to address which is the best Unix shell, you've got to at least mention zsh".
Groovy's just a dialect of Ruby anyway, except being specific for one platform and having a different syntax. All the functionality underneath the syntax is based off Ruby, and even its two applications with any traction are based off Ruby versions. The MOP was put in in 2005 specifically for Grails, which started off as a launder of Rails.
Grails is a bit more than simply Rails for Groovy. There are a few things that Grails does very differently, partly due to it being built on top of Spring and Hibernate.
Also, Groovy+Grails is far more enterprise-ready than Ruby on Rails. Something as basic as proper unicode support is still very recent in Ruby, for example. Also, multithreading comes as naturally to Grails as it comes to Java, but not to Ruby on Rails.
They are absolutely very similar, but there are important differences that go a lot deeper than just the different syntax.
> There are a few things that Grails does very differently, partly due to it being built on top of Spring and Hibernate.
Back in 2005 Grails didn't add much to Groovy, Spring, or Hibernate. It was just a thin wrapper around software products from other companies (e.g. SpringSource, JBoss) so the training consultant behind it all could muscle in on the training and consultancy markets for their products. In 2006 Grails was renamed and promoted as _Groovy on Grails_ to sound like _Ruby on Rails_. He started a company, G2One Inc, in 2007 and quickly shopped it around among the various companies whose products he bundled, successfully fooling SpringSource into buying it 12 mths later.
I don't know that I'd call Groovy a dialect of Ruby. Sure, it's features are _inspired_ by Ruby but there are many very significant differences. No magic undeclared variables as a simple example. Another example is the categories feature, which Ruby doesn't really have. Not to mention that the syntax is completely different.
Progress is when languages move from the unreasonable list to the reasonable list. I was happy to see Haskell there. I don't think it would've been 5 years ago.
This was an excellent article. Agree with the author on many points. Some notable mentions:
- Scheme: One of the best languages. A shining example of the beauty of simplicity. I personally envy folks that got to learn programming with SICP. Unfortunately, I didn't crossed with the SICP as a kid, when I would probably had devoured it.
- Haskell: possibly the most advanced programming language,
with the downside of having way too much syntax.
- Opinions on programming languages are biased most of the time. Significant experience with dozens of languages is required, to diminish the bias.
Haskell too much syntax? That's a very weird claim. Haskell's syntax is one of the leanest around.
You could even argue the lack of syntax can be confusing sometimes. Beginners often mix up types, patterns and expressions, because there isn't a huge syntactic difference.
Yeah, that surprised me as well. There are declarations of types and classes etc which are a bit confusing at first, and then there are `do` and `case` and the like. Certainly not a lot though, compared to say C++ or Scala. I think what might make it appear more difficult is that it's just so different from almost anything else out there, so it's not just that there's a bit of new syntax to learn, but that almost nothing that you've learned in other languages will be applicable.
That is more or less what I mean by Haskell having too much syntax. Let me start by saying that I am far from an expert, and I am just expressing a subjective opinion. I would welcome if anyone shows me that I am wrong. Haskell is a brilliant language. Yet I have this personal and completely subjective opinion. When using Haskell, I get the feeling that the different syntax constructs, just don't fit too well conceptually among them.
The language on the whole is far superior to most others. Yet the syntax constructs don't feel to fit elegantly to me. It is not just that purely functional is a completely different paradigm. It is that the actual implementation lacks a global conceptual elegance. I am going to give an actual example: Take pattern matching. That is a nice conceptual idea. You can pattern match in function, and it is great. But then, you can also pattern match in list comprehensions. So patter matching can be combined in two completely different operations. This does not feel elegant, it feels awkward. It is not very obvious where pattern matching can or can not be used. Haskell is full of things like this.
This lack of overall elegance, makes it harder to mentally handle and become agile with the language. It takes more effort, so it feels that the it has a substantial cognitive overload. Maybe this is completely fine, and is required for the benefits of purely functional programming. Or maybe there could be a different, more elegant implementation of a purely functional language.
Or maybe I'm just biased by a lack of extensive experience with dozens of languages. As a fun note, let me add that as a side project, I am currently at work on a programming language, that address these things that I see as problems. It is not a purely functional language that aims to compete with Haskell, but it happens to address the issue of lack of overall elegance, that I am describing here. I currently have a conceptual design for a type system that specifically aims for conceptual elegance within the whole language. Also it happens that this language will be a graphical language, instead of text based. At worst it will be a great learning exercise for me. I hope that it at least end being an interesting curiosity.
He means that Haskell has a lot of operators. Haskell code is often very symbol-heavy instead of word-heavy, which IMO can make it hard to read. It reminds me of Perl in that way.
> If there is something that could debunk C is a low-level language with great support for concurrency. Or maybe a mythical language with the properties of Haskell and the pervasiveness of C.
So, Rust? :) (Minus the pervasiveness, right now—but you do have the low-level control.)
Yes, that is correct. Bash has additional functionality (and the for-loop I showed could very well be a part of that). If you want posix, better stick to dash, the code he showed.
But bash with its additional features (like associative arrays) is much more comfortable, so if you know you can use bash - because the target is GNU/Linux - it is a good idea to use them.
Whenever someone says PHP is useless I know that they have no idea what they are talking about. Being ugly is one thing, being useless is something quite different and in case of PHP this could not be further from the truth.
A bit surprised by how much attention this article is getting here. Someone nailed it by saying it has much breadth but little depth. A speed dating synopsis of competing programming language to speak. Obviously the author likes brunettes with fair skin.
I recall reading the "Design and Evolution of C++" and found it quite enlightening. One wishes this type of book was a mandatory delivery for all Language authors...
That's a big list. A relatively inexperienced programmer looking for advice on what language to start with would probably be overwhelmed. How to choose what language to learn next? There's a dozen languages they've never heard of on there.
Glad to see Bash on there, even if his example code was sort of misleading. Sure, you have to be able to read that stuff, but if you can rely on Bash being there, you can use better syntax.
Anyway, Bash (and other similar shells) is special because it's the glue that ties a Unix system together. No other type of language can construct the same kinds of pipelines and filters so concisely or interact with the filesystem so easily. For a certain set of problems, Bash is by far the best option. The ugliness is partially legacy, but mostly just necessary to allow the same language to work at the command prompt without overloading everyday CLI usage with a ton of pointless syntax. It's all about tradeoffs, kids.
People should first decide what they want to achieve, produce mobile, web, or desktop applications, etc.
Then they should find the best framework to achieve their goals. The language is usually force upon you by the framework unless you're working on something cutting-edge.
In the past, when I set out to learn a programming language, I would always get nowhere. You learn the syntax from some book, do the exercises, then what? Without a solid goal to hack toward, pretty soon, you will forget everything you've just learned.
Sure, but that doesn't mean both organization are equally committed to each language. Google has an entire team that works on Go full time and all their work is donated to golang.org which is opensource. Its not clear that Facebook is more than just a D user at this point.
I also have a seeking suspicion that Facebook never considered using Go because of Go's close Google ties, maybe if they didn't feel Google was a competitor they would have went with Go over D- we will never know.
As I understand it, they didn't 'go with D over Go' so to speak. They employ a fanatic of the language who wrote a piece in D, presumably with approval, and used it. There's nothing wrong with any of that, and I hope it works well for them. But I wouldn't say it was exactly chosen in advance for its merits, other than having an awesome programmer in the language, which can be one of the biggest reasons at times.
GREPTHIS()
NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="RETURN",THEN="KILL"
IF IF=THEN DO THEN
QUIT:$QUIT QUIT QUIT ; (quit)
THEN IF IF,SET&KILL SET SET=SET+KILL QUIT
"[Java]’s used for everything, from web apps to games. Almost everything except embedded device software, and perhaps high performance parallel computation software."
Apparently hasn't ever heard of Embedded Java or Hadoop
Just because you decide that someone is "biased" doesn't mean that you don't have to address their arguments specifically. We have more reason to think he knows what he's talking about than to think that you do.
If you actually want to make things you'll still can't avoid learning C, C++, Java and/or Objective-C. Other languages just don't offer a broad enough ecosystem.
You can get very far with Ruby or Python before having to learn a bit of C for extensions. I've been using Ruby for years and I've yet to run into a situation where I need it, though admittedly I stick to web stuff.
Don't get me wrong, I'm a big fan of high-level programming languages. But things like threading, graphical interfaces, multimedia, embedded programming, binary distribution etc. just isn't very well supported. Partly because of technical challenges, but mostly because there isn't a critical mass of people doing those things.
I'd use Clojure over Common Lisp any day of the week, but I'd never call CL a "dinosaur language". It's still getting a lot of use, and it's still a better language than what 90% of programmers have to use in their day jobs.
I like one point he made about Clojure's real killer strength: it works for exploratory code and in production. You don't have to use one language for data analysis (e.g. R) and another one for your production servers (e.g. Java) which means that the data-science/production-engineer impedance mismatch need not be as severe. Here's a presentation I gave on that aspect of Clojure (note the Venn diagram): https://docs.google.com/presentation/d/15-7qFy6URdE7Owi2Litk...
On Haskell, he says: "This language truly feels as a more advanced thinking tool than the others in this list. It has libraries for almost any need and it has a hard-core community."
You know, a few years ago I looked into Haskell and thought, "this language is amazing" but wrote it off because (a) it didn't seem to have the libraries for "practical" corporate programming (CRUD apps) and (b) the political fight to get to use Clojure at your job is at least theoretically winnable due to the JVM; for Haskell, it's not winnable until you are the architect or boss man. I like static typing a lot (I used Ocaml at Jane Street for a year and a half) so Haskell always seemed appealing, if not practical for "most kinds of work".
I'll probably stick with Clojure and Scala, because I'm not yet at that point in my career where I can use/do whatever the fuck I want, but I'm inspired to look into Haskell more.
A few people recommended I check Haskell out again. The community has made major strides (or, to put it more directly, it's kicking ass). I spoke to @cartazio about it the last time I was up in New York and he made a really convincing case for Haskell being ready to tackle the hardest of the hard problems (e.g. machine learning problems where performance and high-level code are both needed).
It's a dead horse and people can't help but beat on it as they pass by.
I wouldn't call it a dinosaur language either. The specification of Lisp that we call, "Common Lisp," was ratified by ANSI in 1994 -- putting it almost neatly between ANSI C (1989) and ANSI C++ (1998). Common Lisp just has a longer history than those two languages so it tends to get flack from the young'uns and ignoramus' for being, "old and crufty."
It's a small community but there are plenty of libraries, tools, and compilers under active development.
Since you like strong typing and use Clojure, have you checked out Typed Clojure yet?
I'm sure you have heard of it, but it seems obligatory to mention it in any discussion of programming languages involving both Clojure and Haskell, or Clojure and type systems, or Scala and anything, or...
Please check your facts before posting to avoid being a clueless moron: C# is not just a static language it supports dynamic typing, C# is not just an object-oriented language it's a functional language as well.
The post is downright offensive to C# developers.
EDIT: ok, I figured it out - it's a troll post to stir the HN community a bit. Lot's of other good languages get undeserved bashing.
C# is most definitely not a functional language. It has a few functional constructs, and it's possible to (painfully) code in a superficially functional style, but a "functional language" it isn't.
I disagree that just providing functional constructs makes a language a "functional language". How mutable state, purity, and recursion are handled have quite a bit of say in whether a language is functional.
For PHP he comes out of the gate saying "Don’t just assume PHP is horrible."! Apparently the ONLY redeeming quality of PHP is the vast number of developers who know PHP?
Yes PHP is horrible,but it is usefull,otherwise nobody would use it.It has excellent libraries for "traditional" user facing websites. It's clearly not meant to do anything else.
