POV-Ray : Newsgroups : povray.off-topic : Interesting point/counterpoint on HLLs Server Time
5 Nov 2024 00:27:29 EST (-0500)
  Interesting point/counterpoint on HLLs (Message 1 to 6 of 6)  
From: Darren New
Subject: Interesting point/counterpoint on HLLs
Date: 28 Mar 2009 14:30:04
Message: <49ce6cac@news.povray.org>
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. :-)

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

From: Warp
Subject: Re: Interesting point/counterpoint on HLLs
Date: 28 Mar 2009 15:00:14
Message: <49ce73be@news.povray.org>
Darren New <dne### [at] sanrrcom> 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

From: nemesis
Subject: Re: Interesting point/counterpoint on HLLs
Date: 28 Mar 2009 16:05:01
Message: <web.49ce82d2bb0eba189933902e0@news.povray.org>
Ah, old arguments are always fun. :)


Post a reply to this message

From: Darren New
Subject: Re: Interesting point/counterpoint on HLLs
Date: 28 Mar 2009 16:52:37
Message: <49ce8e15@news.povray.org>
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

From: clipka
Subject: Re: Interesting point/counterpoint on HLLs
Date: 28 Mar 2009 21:05:01
Message: <web.49cec89bbb0eba1822390e420@news.povray.org>
Warp <war### [at] tagpovrayorg> 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

From: Warp
Subject: Re: Interesting point/counterpoint on HLLs
Date: 29 Mar 2009 03:02:52
Message: <49cf1d1c@news.povray.org>
clipka <nomail@nomail> wrote:
> 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.

  But those are features of Visual Studio, not features of C#.

  That's a bit like saying "I really like C++ because emacs has such a good
support for code coloring and autoindentation for it".

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.