The Best Programming Language (or How to Stop Worrying and Love the Code)
blog.fourthbit.com
blog.fourthbit.com
edit: I'm not just blowing hot air, I've actually wrote C# code that went into production.
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.
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)
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).
http://channel9.msdn.com/shows/Going+Deep/Bart-De-Smet-Obser...
0: http://www.amazon.com/dp/1590597893/
To that end Jon Skeet has already documented how to do it in his Edulinq series[0][1].
[0] Link to series: http://msmvps.com/blogs/jon_skeet/archive/tags/Edulinq/defau...
[1] Download of series (found in link): https://code.google.com/p/edulinq/downloads/list
Although this blog is dead now, the information stored within is golden. I also highly suggest De Smet's C# 5.0 unleashed book.
LINQ alone makes C# infinitely less verbose and 'boilerplate' than Java.
My biggest interest in .Net/CLI/Mono from very early on was how much easier it was to interface with systems libraries vs. Java's JNI.
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.
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.
Enjoy!
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.
Like F# classified as one of "unreasonable langauges" on the basis that "we have enough company-sponsored languages already"
http://rxwiki.wikidot.com/101samples - A cursory look; it goes far deeper than this.
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 :]
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.
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.
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.
It does offer good job security, however.
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.
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.
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:
There are only two kinds of languages: the ones people complain about and the ones nobody uses - Bjarne Stroustrup, http://www.stroustrup.com/bs_faq.html#really-say-that
I take the view that all languages are ugly and stupid, especially languages like C and English.
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:
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)
If a new language has curly braces is instantly reviled and deemed as "not innovative" by part of the community.
You're exactly right.
{ Number. #someSymbol. 5 + 6. [ :anArgument | anArgument doSomething ] value: 'some string goes here'. #(3 'hi'). 1000 factorial }
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.
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...).
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.
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.
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.
http://ocaml.org/community/support.html#TheCamlConsortiumatI...
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.
When to use it? When you want the JVM, and productivity is a bigger concern than performance.
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.
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.
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.
- 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.
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.
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.
So, Rust? :) (Minus the pervasiveness, right now—but you do have the low-level control.)
for i in {0..5};do
echo "$1"
doneBut 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.
for i in `seq 0 5`; do
echo "$i"
done
Efforts are also underway to spruce things up a bit. https://github.com/fukamachi/cl21
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...
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.
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.
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.
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
Apparently hasn't ever heard of Embedded Java or Hadoop
Author loves javascript.
> you can’t really be objective. So yes, I’m biased.
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.
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...
Simula-67 would like to have a word with you...
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.
It has type inference(static, but you don't have to declare types), straight out of functional languages.