51–60 of 110 posts
If C isn't suitable for projects with more than 10K lines, then praytell, what language should my kernel be written in? I've been meaning to try Go for a while (the fast compile times alone intrigued me), but this type of post really just puts me off - if you're telling me that C isn't suitable for large projects, then that tells me you may not know C well enough to make that judgement.
Earlier quoted context omitted.
Playstation 2 and Nintendo 64 games were written in assembly? Really? I thought C and C++ were common by then.
You are ahead of yourself by a few years. Q3 came out in 1999, which means it was written in the late 90s, so think PSOne and late SNES/Genesis titles.
> What makes me stay away from it is the non-free nature. Yes, there is Mono, but I wouldn't like to base my stuff on a language that is there because of Microsoft's benevolent permission which it could turn into patent-lawsuits any time. We all know the tricks that company (well, actually any large company) has up its sleeves. Microsoft has standardized C# and the CLR through ECMA, and issued a promise stating that…
So while C may be as lightweight as it can get, it's not really suitable for projects with more than 10k LOC. I believe John Carmack would have something to say about this. http://en.wikipedia.org/wiki/Id_Tech_3
One might think C sucks and still use it. You might think it sucks, but it's still less bad than everything else. Using something doesn't necessarily makes you blind towards its drawbacks. I think a lot of the things I use everyday sucks. But I still use them because there's nothing better... yet.
All those programs written in C that everyone is posting about (quake, linux, gimp etc). Were written before Go existed. So it's very plausible that the authors could agree that C sucks if they had the option to write in Go. Which is the point of the article.
Just from the title I can tell this is going to present a completely objective, well thought-out, unbiased appraisal.
> Go has no exceptions. I'm not a fan of the verbosity of error handling with exceptions either. It is particularly bad for fine grained error handling. However, I do like that the default state of a non-handled error is to propagate and eventually crash the thing rather than continue with errors that may subtly corrupt things. I haven't used Go, but from the explanation of error handling Go seems to do the latter ra…
In Go, the accepted way to report errors is to take advantage of multiple returns, such as: result, err := somePotentiallyFailingFunction() if err != nil { // Try to recover here ... // Not recoverable? panic() } And this call to panic works the way you prefer. Note that doing the following: result := somePotentiallyFailingFunction() won't compile since the number of values on the left doesn't match the right, so if…
Just from the title I can tell this is going to present a completely objective, well thought-out, unbiased appraisal.
This is Hacker News. You have to have a conclusion or command in your title to get upvotes. "Why the cloud is wrong for your business." "Why your language sucks." "SaaS-de-jour, we have a problem."
So, what's fundamentally wrong with JS? Not a lot. At this point the article lost all credibility with me.
Unfortunately some of the implementation details do allow for seriously horrible code and some seriously horrible traps. But if you can clear the fog, and use "the good parts", it's actually pretty nice.
As for the article, I think it's very well written and seems to have a good overview of the language. Also, the author seems to have an above average experience level in an above average number of programming languages (guessing here), so it might be worth a read.
dynamic_cast >(funky_iterator >(foo::iterator_type (obj)) Yeah. Right. Don't get me wrong, I love templates, but contemporary C++ using STL looks like a classic case of the "If all you have is a hammer"-syndrome. GCC had to implement special diagnostic simplifications just so you can actually find out that that 5-line error message was a simple const'ness mistake when using a std::string method. Even worse, they can…
dynamic_cast >(funky_iterator >(foo::iterator_type (obj)) Yeah. Right. Don't get me wrong, I love templates, but contemporary C++ using STL looks like a classic case of the "If all you have is a hammer"-syndrome. GCC had to implement special diagnostic simplifications just so you can actually find out that that 5-line error message was a simple const'ness mistake when using a std::string method. Even worse, they can…
Every language has its pathological corner cases. Modern C++ using the STL is almost as terse as modern dynamic languages but runs 100x faster.