Live data from Hacker News

The Best Programming Language (or How to Stop Worrying and Love the Code)

blog.fourthbit.com

31–40 of 166 posts

Re: The Best Programming Language (or How to Stop Worrying and Love the Code)

#31
post #12

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

+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.

Re: The Best Programming Language (or How to Stop Worrying and Love the Code)

#33
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.

Re: The Best Programming Language (or How to Stop Worrying and Love the Code)

#34
post #33

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.

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?

Re: The Best Programming Language (or How to Stop Worrying and Love the Code)

#35

No love for mumps? 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

(grumpy cat) NO

Re: The Best Programming Language (or How to Stop Worrying and Love the Code)

#36
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).

Re: The Best Programming Language (or How to Stop Worrying and Love the Code)

#37
post #13

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 log…

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.

Re: The Best Programming Language (or How to Stop Worrying and Love the Code)

#39
post #18

Earlier quoted context omitted.

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…

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)

Post reply on HN