101–110 of 166 posts
Earlier quoted context omitted.
Your point?
His opinion is biased and he doesn't know what he's talking about.
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.
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.
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.
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…
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.
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.
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 ha…
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!
Earlier quoted context omitted.
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.
There are a couple smaller LINQ implementations out there like Linq to Amazon that you can take a look at (Linq2 libraries seemed to be coming out of nowhere for a while).
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 hav…
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.
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?
Sams Teach Yourself CPP One Hour a Day 7th and CPP Primer 5th
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'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'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...