Author Topic: What's your favorite language feature?  (Read 3501 times)

0 Members and 1 Guest are viewing this topic.

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 394
  • Country: us
Re: What's your favorite language feature?
« Reply #100 on: July 13, 2020, 12:00:41 am »
They don't have sequential or even well-defined values.
The value of keyword symbols are themselves.  Can't get much more well-defined imho.

Nope. Symbols are *not* self-evaluating.  If you write the bare name of a symbol then it is looked up in the current context and you get whatever it is bound to, not the symbol itself. That's equally true in Lisps and in the C implementation I gave. If you want to refer to a symbol by name -- as a symbol -- then you *have* to quote it by variously putting a ' or a : after it, or perhaps various other things e.g. a # in front if it in Dylan or a * in front of it in Perl or a \ in front of it in PostScript.

Keyword symbols are bound to themselves.  You might want to peruse the standard: http://www.lispworks.com/documentation/HyperSpec/Body/t_kwd.htm
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: What's your favorite language feature?
« Reply #101 on: July 13, 2020, 01:37:16 am »
They don't have sequential or even well-defined values.
The value of keyword symbols are themselves.  Can't get much more well-defined imho.

Nope. Symbols are *not* self-evaluating.  If you write the bare name of a symbol then it is looked up in the current context and you get whatever it is bound to, not the symbol itself. That's equally true in Lisps and in the C implementation I gave. If you want to refer to a symbol by name -- as a symbol -- then you *have* to quote it by variously putting a ' or a : after it, or perhaps various other things e.g. a # in front if it in Dylan or a * in front of it in Perl or a \ in front of it in PostScript.

Keyword symbols are bound to themselves.  You might want to peruse the standard: http://www.lispworks.com/documentation/HyperSpec/Body/t_kwd.htm

Keyword symbols and symbols are different things -- or at least keyword symbols are a subset of symbols. Keyword symbols are a particular Common Lisp feature while I'm talking about a symbol concept that is common across quite a number of programming languages.

To quote from the page you reference:

Quote
Interning a symbol in the KEYWORD package has three automatic effects:

1. It causes the symbol to become bound to itself.

i.e. any symbol that has *not* been interned into the KEYWORD package is *not* bound to itself, and that is most symbols.

 
The following users thanked this post: SiliconWizard

Offline 0db

  • Regular Contributor
  • *
  • Posts: 246
  • Country: zm
Re: What's your favorite language feature?
« Reply #102 on: July 13, 2020, 10:40:07 am »
All the features offered by ucPython on my graphing calculator.
Scripting in ucPython is more productive than CASIO-basic.


 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5447
  • Country: fr
Re: What's your favorite language feature?
« Reply #103 on: July 14, 2020, 04:58:13 pm »
Note that you can replace the standard allocator with a garbage collector in C and C++ if you like that. A well known, and relatively well-behaved one is the Boehm GC: https://www.hboehm.info/gc/

It makes a good attempt at reclaiming most garbage in programs that match its limitations.

Scarcely general purpose.

I've not seen it fail in any significant way. A number of programming languages use Boehm as their GC -- and many others *should*.

I mostly agree with that. If someone is claiming the Boehm GC is flawed, please at least give details, and accurate facts and figures about it. It has been widely used indeed.

Hans Boehm was completely open about what it couldn't do. Apply those to arbitrary programs composed of components (e.g. libraries!) produced by people not working together. Then try to ensure correct operation.

If there is a strict control of all code in a particular environment (e.g. Apple's) then it becomes less intractible - although still difficult and somewhat limited.

So you're basically saying that all projects in which it has worked well must fall into this category. Maybe so. As Nominal Animal suggested, there are still many cases (obviously not ALL) in which just using it as a drop-in for malloc() mostly gives benefits without noticeable problems. It should certainly be tested with care, though. Another point, which may be part of what you are saying, is that ideally you must have access to ALL source code and recompile everything using the Boehm GC. I know there are ways to just kind of redirect malloc() calls at the executable level, but I would certainly suggest NOT doing this. Way too slippery.

But with your claims, it would have been nice to have more details on the exact limitations and how "difficult" it is to use properly. As it is, it's like we'll have to take your word for it. I absolutely don't think it's perfect, but it would have been interesting to have more detailed information if anyone is interested in possibly using a GC with C or C++. (All the more that there are other options, just the this one is one of the most popular.)

Now in the general sense, any allocator that is an integral part of a given language, rather than a third-party addition, is more likely to be more robust, easier to use, and more consistent. No real doubt about that, and if this is what you implied beyond the very case of the Boehm GC, then that's something to consider.

Quote
Note that I was merely pointing out an option for those that would be dead sure you can't have a GC with C or C++. I was not particularly advocating using one, as GCs have specific issues (however good they are) that you don't necessarily want to have to deal with, such as non-predictable execution times. I am also not 100% convinced about garbage collecting in general - it naturally leads to sloppy resource management. You may argue that it will almost always do a better job than even careful "manual" resource management, and I wouldn't necessarily disagree in the general case, but I'm still not sure it promotes completely healthy programming habits, or that it's even the best way of dealing with "automatic" resource (memory) management.

You sound as if you think people are claiming GC is a silver bullet, which would be stupid.

I don't know how you get that from what I said. If it was not clear, all I was saying is that there are actual options for a GC in C and C++, and then I additionally expressed my own (short) opinion on the potential benefits and drawbacks of GC in general.

We can also note that depending on the language you use, you may not have a choice. Some languages rely on GC and don't give you alternatives for dynamic allocation. For people using such a language, whether they consider GC a silver bullet or not doesn't matter - they just have to do with it.

« Last Edit: July 14, 2020, 05:04:59 pm by SiliconWizard »
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 12100
  • Country: gb
    • Having fun doing more, with less
Re: What's your favorite language feature?
« Reply #104 on: July 14, 2020, 05:50:15 pm »
Note that you can replace the standard allocator with a garbage collector in C and C++ if you like that. A well known, and relatively well-behaved one is the Boehm GC: https://www.hboehm.info/gc/

It makes a good attempt at reclaiming most garbage in programs that match its limitations.

Scarcely general purpose.

I've not seen it fail in any significant way. A number of programming languages use Boehm as their GC -- and many others *should*.

I mostly agree with that. If someone is claiming the Boehm GC is flawed, please at least give details, and accurate facts and figures about it. It has been widely used indeed.

Hans Boehm was completely open about what it couldn't do. Apply those to arbitrary programs composed of components (e.g. libraries!) produced by people not working together. Then try to ensure correct operation.

If there is a strict control of all code in a particular environment (e.g. Apple's) then it becomes less intractible - although still difficult and somewhat limited.

So you're basically saying that all projects in which it has worked well must fall into this category. Maybe so.

No I'm not saying that. If I say that all crows are black birds, it does not mean I say all black birds are crows.

Quote
As Nominal Animal suggested, there are still many cases (obviously not ALL) in which just using it as a drop-in for malloc() mostly gives benefits without noticeable problems.

The keywords there are "mostly" and "noticeable".

As Tony Hoare memorably put it "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

It is obvious which category a product made with Boehm's GC falls into.

Quote
It should certainly be tested with care, though.

Remember the old engineering adage: "you can't test/inspect quality into a product". Why is it that too much of the software industry doesn't comprehend that tests cannot show the absence of bugs, they can only show the presence of specific bugs?

Quote
Another point, which may be part of what you are saying, is that ideally you must have access to ALL source code and recompile everything using the Boehm GC. I know there are ways to just kind of redirect malloc() calls at the executable level, but I would certainly suggest NOT doing this. Way too slippery.

Absolutely. That is not practical for many reasons.

Quote
But with your claims, it would have been nice to have more details on the exact limitations and how "difficult" it is to use properly. As it is, it's like we'll have to take your word for it.

Do not take my word for it! Read the literature to understand what the creator (and others more knowledgeable than me) have said. I'm not going to repeat it poorly!

Quote
I absolutely don't think it's perfect, but it would have been interesting to have more detailed information if anyone is interested in possibly using a GC with C or C++. (All the more that there are other options, just the this one is one of the most popular.)

Popularity is irrelevant.

If I'm allowed to create a product that doesn't work, I can do it in 10 minutes flat.

Quote
Now in the general sense, any allocator that is an integral part of a given language, rather than a third-party addition, is more likely to be more robust, easier to use, and more consistent. No real doubt about that, and if this is what you implied beyond the very case of the Boehm GC, then that's something to consider.

I will try to stop people using inappropriate tools when more appropriate tools are available. Familiarity with an inappropriate tool is not a valid reason for using it.

For example, I've seen people open tin cans with scissors :)

Quote
...
We can also note that depending on the language you use, you may not have a choice. Some languages rely on GC and don't give you alternatives for dynamic allocation. For people using such a language, whether they consider GC a silver bullet or not doesn't matter - they just have to do with it.

That doesn't mean it is sensible, nor appropriate, nor correct.

Example. I've seen somebody that needed to get a value from one unix process to another running on a different processor. Since he only knew SQL he just had to use that. Yes, his solution was the first process updated a database table, and the second process polled the database table (using SQL SELECT) to spot changes.

Sane people would just have started with TCP/IP, not SQL!
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2690
  • Country: tr
Re: What's your favorite language feature?
« Reply #105 on: July 14, 2020, 06:00:51 pm »
Sane people would just have started with TCP/IP, not SQL!

Or a pipe.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: What's your favorite language feature?
« Reply #106 on: July 15, 2020, 12:20:42 am »
As Tony Hoare memorably put it "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

It is obvious which category a product made with Boehm's GC falls into.

Any program which uses explicit malloc() and free() which are not in the same control flow block (and which could therefore just as well use alloca() or even a local variable) has already exited from the first category.

It is an enormous simplification and contribution to reliability to debug the GC once, not debug every malloc() and free() in every program.

GC is a huge aid in making separately developed libraries work together. As are exceptions.

Very simple libraries can work ok without those, but as soon as you have anything that uses callbacks (or calls methods on an object you pass it, which can be of a derived class of the class the library was written for) then you need both.

It's very hard to see how substituting GC for free() in a C program that is bug-free can produce a buggy program. Some objects that would be free()d may never be collected if pointers to them are not zeroed after free() or overwritten with a new pointer sometime after. This effect is strictly limited and can not lead to a continuous leak that does not exist in the malloc/free version.

In C++ making delete a no-op results in destructors not being called. The vast majority of destructors do nothing more than delete other objects, in which case it doesn't matter.

The case that matters is if a destructor deallocates or closes some external resource such as a file or network port or sends a message to another process etc. However this is a rare style of programming. Usually such things are done by explicit function calls controlled by program logic, by nested control structures, or by RAII.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 12100
  • Country: gb
    • Having fun doing more, with less
Re: What's your favorite language feature?
« Reply #107 on: July 15, 2020, 10:57:21 am »
As Tony Hoare memorably put it "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

It is obvious which category a product made with Boehm's GC falls into.

Any program which uses explicit malloc() and free() which are not in the same control flow block (and which could therefore just as well use alloca() or even a local variable) has already exited from the first category.

It is an enormous simplification and contribution to reliability to debug the GC once, not debug every malloc() and free() in every program.

GC is a huge aid in making separately developed libraries work together. As are exceptions.

Very simple libraries can work ok without those, but as soon as you have anything that uses callbacks (or calls methods on an object you pass it, which can be of a derived class of the class the library was written for) then you need both.

Agreed on all counts.

Quote
It's very hard to see how substituting GC for free() in a C program that is bug-free can produce a buggy program. Some objects that would be free()d may never be collected if pointers to them are not zeroed after free() or overwritten with a new pointer sometime after. This effect is strictly limited and can not lead to a continuous leak that does not exist in the malloc/free version.

In C++ making delete a no-op results in destructors not being called. The vast majority of destructors do nothing more than delete other objects, in which case it doesn't matter.

The case that matters is if a destructor deallocates or closes some external resource such as a file or network port or sends a message to another process etc. However this is a rare style of programming. Usually such things are done by explicit function calls controlled by program logic, by nested control structures, or by RAII.

Here we are diving into discussing the characteristics of some programs plus libraries plus a/one GC retrofitted to a language that was not designed to allow GCs. At this point things are becoming complicated to the point of being intractable. It would be too easy to miss a particular case that does turn out to cause infrequent subtle problems, possibly only when more aggressive optimisations are enabled and/or when third party libraries are linked in.

Given the demonstrable inability of most C/C++ programmers to understand all the language and implementation "gotchas", it looks like building castles on sand. N.B. I'm quite prepared to believe that a relatively few experts could build a useful castle on sand.

Overall, if you need GC then:
  • if you are starting from a clean sheet, then best to use a language designed with GC in mind. If desirable, it should then be possible to adopt programming styles that don't generate much (if any) garbage. At that point any "GC overhead" becomes moot. Some fintech Java libraries/products do that.
  • if you can't start from a clean sheet but have to use pre-existing components, then predicting and ensuring there aren't subtle infrequent problems related to GC seems a tall order. Best to avoid GC altogether

Summary of the summary... We have enough interesting problems to solve in our various application domains. Life is too short to spend debugging additional uninteresting problems that are avoidably added by a tool. Let's concentrate on the application, not on the tools.
« Last Edit: July 15, 2020, 11:00:57 am by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: What's your favorite language feature?
« Reply #108 on: July 15, 2020, 01:27:00 pm »
The first paper on BDW GC was published in 1988: https://hboehm.info/spe_gc_paper/preprint.pdf

That's over 30 years of experience with this software. on many CPU architectures, dozens of compilers, who knows how many thousands of programs. My own experience with Boehm GC is around 22 years.

If there were significant problems with the overall approach, in the face of C programmer habits or compiler optimizations, I think we'd know by now.

There *have* been problems found over the years, and they have been fixed or mitigated.

If you're going to write a program using dynamic memory allocation at all, I firmly believe if you use Boehm GC then it and its interaction with arbitrary C or C++ code is the LEAST LIKELY place you will encounter bugs, and using it instead of malloc/free or new/delete will VERY significantly decrease the overall probability of your having memory bugs.
 
The following users thanked this post: SiliconWizard

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 12100
  • Country: gb
    • Having fun doing more, with less
Re: What's your favorite language feature?
« Reply #109 on: July 15, 2020, 02:19:32 pm »
The first paper on BDW GC was published in 1988: https://hboehm.info/spe_gc_paper/preprint.pdf

That's over 30 years of experience with this software. on many CPU architectures, dozens of compilers, who knows how many thousands of programs. My own experience with Boehm GC is around 22 years.

If there were significant problems with the overall approach, in the face of C programmer habits or compiler optimizations, I think we'd know by now.

There *have* been problems found over the years, and they have been fixed or mitigated.

If you're going to write a program using dynamic memory allocation at all, I firmly believe if you use Boehm GC then it and its interaction with arbitrary C or C++ code is the LEAST LIKELY place you will encounter bugs, and using it instead of malloc/free or new/delete will VERY significantly decrease the overall probability of your having memory bugs.

I thought it was a 90s invention rather than 88, and I'm sure your experience is valid. I'm not surprised there have been problems found (and fixed); I certainly haven't been following the subject. I'm mildly curious (in a rather prurient way) as to the way the bugs were found, reported, believed, and fixed. I don't expect you to set them out, though!

I also have no difficulty believing that it is less error prone than "traditional" malloc/free/new/delete. But that's an unacceptably low bar to set! :)

But overall the balance of probabilities is that if you are starting a new application with significant dynamic memory allocation, then there have long been better tools available. The existence of Boehm's GC highlights that - but doesn't change that.
« Last Edit: July 15, 2020, 02:33:21 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf