|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> http://www.netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/
> http://www.modernperlbooks.com/mt/2009/03/in-praise-of-high-level-languages.html
> I think they both make some good points and some bad points. :-)
I failed to see the good points in the first article. What are they?
Personally I hate C more than I hate Java. I wouldn't want to make any
project, minuscule or large, in C.
C++ has its own quirks and problems too (being inherited from C and all),
but in most cases (especially in very small projects) it allows me to
concentrate on the *algorithm* I'm implementing, rather than all the
ancillary stuff I need in order to implement it (eg. data containers).
As a concrete example, I recently wanted to write an anagram generator,
partially because I couldn't find any which I would have liked and which
would support defining a custom dictionary, and partially because I liked
the challenge. Handling the data and trying to make it fast required
dynamic data containers, sorting, binary searches and such. C++ allowed
me to start implementing my ideas *right away* because I didn't have to
waste any time at all on the data containers (and trivial algorithms like
binary search).
Also he writes that he "trusts" C programmers more than higher-level
programmers.
One good thing about open source projects is that you actually get to
see what kind of code they write. Well, take the sources of almost any
big C project out there and take a look at them. Have some brain bleach
prepared. One example project which you could try is mplayer and its
codecs. It's just plain HORRIBLE.
I wouldn't trust these C hackers for anything. They don't know the first
thing about programming.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> I failed to see the good points in the first article. What are they?
I think we can both agree that monkey patching sucks. :-)
Depends on how big he thinks a "large" project is. And I don't "trust" C
code more than I trust Java or C#. Experience leads me to believe that there
are more security holes in C programs than in safe (or even
by-default-checked) languages, which just stands to reason.
> Personally I hate C more than I hate Java. I wouldn't want to make any
> project, minuscule or large, in C.
I like C. I've done 40,000 lines of C where I was the main author and we had
2 other people working on it. We started with good specs (basically, BASIC
programs that already did pretty much what we wanted), but it was also in
the days of 33MHz computers with 640K of RAM that took 2 hours to link the
program.
The data containers weren't that difficult - stuff like spreadsheet-like
tables of constants, data for help files and report generation, etc. The
algorithms weren't too hard. It was business computing, not scientific
computing. We didn't wind up with many or any memory leaks. (This included
everything from screen management and single-character console input, input
forms and screens, flexible report generation, computations that were
complicated but not complex (life insurance accounting is complicated but
not complex), and so on.
Now, granted, I didn't maintain it for 5 years, but there was no good reason
why it wouldn't keep working with a bit of care in upgrading the
calculations and such.
As for strings, I allocated strings from a circular buffer, so we could do
things like
printf("%s", concat(mid(upper(his->name), 3, 20), lower(his->city)));
and not worry about the intermediate strings. The stuff like records from
the help and configuration files were managed similarly.
Header files were generated automatically by editor macros based on the
public declarations in the source files, so that kept out that kind of bug.
I've also done a variety of "library" type things in C, where the
performance rules were such that I couldn't copy buffers (for example).
Again, it was pretty straightforward to design. The callers had to follow
the rules, but they weren't hard to follow.
Which isn't to say that C++ isn't far superior for that stuff, because it
lets you centralize all those sorts of things in the classes.
> C++ has its own quirks and problems too (being inherited from C and all),
> but in most cases (especially in very small projects) it allows me to
> concentrate on the *algorithm* I'm implementing, rather than all the
> ancillary stuff I need in order to implement it (eg. data containers).
Agreed. In small projects, the higher level languages win. When you're
coding something from scratch for a year with three people? Hmmm... Not so
clear. Most of the time is going to be spent chasing requirements and
designing stuff. When your program is simple enough to build without having
written specs first, it's going to be easier to use a higher level language
with built-in data structures.
I think it's not really the fact that a langauge is "high level". I went
back and looked at some old Erlang I wrote about 6 months ago. It's ugly, in
large areas unreadable, and would be hard to maintain. Not because the
language is "low level", but because it lacks powerful data structures, and
the program is trying to manipulate data structures with a simple API and a
complex implementation.
> Handling the data and trying to make it fast required
> dynamic data containers, sorting, binary searches and such. C++ allowed
> me to start implementing my ideas *right away* because I didn't have to
> waste any time at all on the data containers (and trivial algorithms like
> binary search).
I think that's what I'm referring to. The built-in structures are more
important than the details of the language. (At least once you have a
reasonable language actually designed for humans, rather than something like
brainfuck or whatever it's called.)
But when you get into a program that does a whole bunch of stuff that's
using conceptually simple data, the existence of pre-defined data structures
is a lot less useful.
Now, something like Open Office, in C? Awful. The data is too complex.
Something like a calendar program, or a network protocol, or some such? No
problem.
> I wouldn't trust these C hackers for anything. They don't know the first
> thing about programming.
Hmmm... Well, I think there's a couple kinds of open-source code.
1) Stuff written by someone who needed to solve a particular problem, who
then released it.
2) Stuff written by someone planning to make it look good, work well, and be
maintainable and valuable (like, say, OpenOffice).
I've seen good stuff in proprietary code, and awful stuff in proprietary
code. I've *written* awful stuff in proprietary code (in HLLs at that), when
the business demands were such that it made sense to do so.
I'm betting the very first version of the Linux kernel was pretty hacky too,
for the same reasons: it was done to learn how to do it, and Linus didn't
really care if others took it over or not, as I understand it.
If you start out not knowing what you want, then stopping as soon as it's
good enough for the original author to use, you're gonna have crappy code,
regardless of the language.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> wrote:
> Personally I hate C more than I hate Java. I wouldn't want to make any
> project, minuscule or large, in C.
Personally, there's not many languages I hate - because I like some challenge
now and then.
But from all languages I've ever seriously tried to write software in, C# felt
the most comfortable. All despite the fact that when I first had a look at it,
I was strongly biased against it. After all, what good could come from MS
except some new hype?
But then again, it's probably not just the language, but even more so the tools
I have at my disposal, and frankly there are not many languages for which I got
out of my way to get some full-fledged dedicated IDE (unless it came with the
language), so maybe I'm not doing justice to some of the languages out there.
Anyway: I guess what got me most in favor of C# is Visual Studio's code
refactoring support. Renaming methods, changing order of parameters, and
what-have-you - all just a few mouse clicks away. Including the reassuring
feeling that it doesn't break anything, because this thing is not just a pimped
brain-dead find & replace - this thing knows what it does.
I can't think of anything more valuable to software development than real good
refactoring tools. I guess if I had the choice, maybe I'd even go for it over a
debugger.
Ah, and by the way: I'd for sure rather work on a well-managed C project, than
on a badly managed Java one.
Post a reply to this message
|
![](/i/fill.gif) |