Live data from Hacker News

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

blog.fourthbit.com

61–70 of 166 posts

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

#61
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…

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?

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

#62
post #25
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

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.

What features? Many of those trace back to Smalltalk and Lisp with some Eiffel as well.

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

#63
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…

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?

Check Tour of C++, recently published by Bjarne.

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

#66
post #63

Earlier quoted context omitted.

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?

Check Tour of C++, recently published by Bjarne.

Wow, thanks, I'd been looking for this too, and somehow had failed to come across that one. Sounds perfect.

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

#67

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

> I'd never call CL a "dinosaur language".

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.

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

#68
post #38

The bash-example is not very bashy. It is sh, like the header says. Bash fully supports a native for: for i in {0..5};do echo "$1" done

Interestingly, this comment states that Bash is not available in all POSIX. Here is where I get lost. http://blog.fourthbit.com/2014/03/01/the-best-programming-la...

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.

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

#69
post #62
post #25

Earlier quoted context omitted.

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.

What features? Many of those trace back to Smalltalk and Lisp with some Eiffel as well.

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.

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

#70
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…

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.
Post reply on HN