Language feature selection

On 3/7/2017 12:02 PM, Simon Clubley wrote:
> On 2017-03-05, Don Y <blockedofcourse@foo.invalid> wrote:
>> A quick/informal/UNSCIENTIFIC poll:
>>
>> What *single* (non-traditional) language feature do you find most
>> valuable in developing code?  (and, applicable language if unique
>> to *a* language or class of languages)
>
> Non-traditional in today's environment only or non-traditional
> over the whole of computing history ?
>
> You sound like you are asking for language features which would be
> considered non-traditional in today's world only.

No.  I'm letting the respondent(s) define what they consider to be
"traditional" -- as pertaining to *their* historical experiences.

I.e., what features were "wow" when *you* encountered them and
that *you* have decided are "invaluable" (which is yet another
layer of subjectivity as it is driven by YOUR application
domains, etc.)

If you learned your (basic) skills using procedural languages, you
might consider OO features as a simple REPACKAGING of the same -- *or*
something "revolutionary".  Moving from ASM to a HLL might leave
you giddy that you can write an infix arithmetic expression instead
of moving "bits" around "memory locations" with special "operators".

> As such I would offer you the strong typing as seen in the Wirth
> languages or (especially) Ada. A person who only knows Javascript
> and C would probably consider C to be strongly typed. A person
> with Wirth languages (or especially Ada) in their background
> would have a different viewpoint.
>
> I think we are losing something if we continue the move away from
> strongly typed languages for various application domains. I really
> like the discipline that strongly typed languages force upon you
> as I think you produce better code as a result.

Agreed.  Note, however, that you can still use type information
in other "informal" ways even if the compiler refuses to enforce
*strict* type checking.  E.g., defining a synonym for a particular
"built-in" type and using that consistently AS A DOCUMENTATION AID.
     "No, this isn't an 'integer' -- even though the underlying
     type FOR THIS IMPLEMENTATION happens to be an 'int'.  Instead,
     it is a 'color' and you should think of it as such when you
     operate on it as well as take note of how it is used..."

[When I code in poorly typed languages like C, my code is littered
with superfluous casts to make it clear to the reader that the
object in question needs to (magically) be converted from one type
to some other type.]

The problem with TOO strong of type casting is that it can get in
the way of efficiency (even if there are no run-time costs, it
can add to the cognitive load as readers are forced to perpetually
consider: why is this type conversion needed, here?) as folks
tend to resist thinking PURELY in the abstract (and, thus, can
not avoid thinking that converting a 'color' to an 'integer' is
just a waste of glyphs on the page!)

> PS: I'll let you decide if you consider Ada to be a Wirth language
> or not. He didn't design it but it's very strongly based on his
> language concepts.

Ada is a great example of how type checking can get in the way
of "efficiency".  Too few practitioners, too bulky validation efforts,
etc. -- so, too little code placed into use.  And, it works *hard* to
keep you from doing things that you "shouldn't do" -- even if you *need*
to do them!  ("OK, but you will HAVE TO do them *this* way...")

[One can argue that *released* Ada code may be of higher quality.
But, if it doesn't make it out of the lab, it's LESS useful than
some buggier piece of crapware that *almost* works!  You don't see a whole
lot of FOSS *Ada*-built products!  :> ]

On 3/6/2017 2:40 AM, David Brown wrote:
> On 06/03/17 00:03, Don Y wrote:
>> A quick/informal/UNSCIENTIFIC poll:
>>
>> What *single* (non-traditional) language feature do you find most
>> valuable in developing code?  (and, applicable language if unique
>> to *a* language or class of languages)
>
> What do you mean be "non-traditional"?
>
> The two languages I find most useful in developing embedded code are
> English and C, followed by Norwegian, C++ and assembly.
>
> If these count as "traditional", then maybe it would be Python - that's
> the language I use most for scripts, auxiliary programs, test programs,
> etc.

The main language feature I like is the ability to interact with and 
test code without having to recompile or deal with a complex debugger. 
Forth provides that with an interpreter that can run on the host or in 
some cases the entire tool runs on the target so there is no host/target 
dichotomy.

Last year I was able to work on a TI ARM kickstart board remotely by 
using a simple terminal emulator over my network.  The entire tool ran 
on the ARM board with the files and editor on my laptop.  Mind you this 
was not a cell phone type ARM processor, this was a Stellaris CM3 device 
with a few kilobytes of RAM.

-- 

Rick C

Op 07-Mar-17 om 18:31 schreef Don Y:
> On 3/6/2017 12:04 AM, Wouter van Ooijen wrote:
>> Op 06-Mar-17 om 00:03 schreef Don Y:
>>> A quick/informal/UNSCIENTIFIC poll:
>>>
>>> What *single* (non-traditional) language feature do you find most
>>> valuable in developing code?  (and, applicable language if unique
>>> to *a* language or class of languages)
>>
>> I can't think of any language feature that is usefull in isolation.
>
> You, of course, wouldn't use *a* "single-feature language" for anything!
>
> OTOH, there are certain features of certain languages that are more
> useful/valuable than other "features".

IMO no. The most usefull feature of a language is that its features work 
well together.

I am a C++ fan, mainly because it enables me to do a lot at 
compile-time. But the C++ features that enables this were, especially 
pre-C++11, (templates) rather clumsy to use. C++14 constexptr is much 
better designed an mostly a joy to use (bit there are still a few rough 
edges).

I am alos a Python fan, but certain aspects of the Python libraries make 
me sick, for instance the s.f() versus f( s ) variations, and the b = f( 
b ) versus f( b ) confusions.

These are examples of features that seem OK in isolation, but don't work 
well with other features. But if I'd have to mention a C++ feature, it 
is the ability to do things at compile time. But that more a concept 
realised by a number of features than a single language feature.

Wouter "Objcets? No Thanks!" van Ooijen

On 2017-03-05 5:03 PM, Don Y wrote:
> A quick/informal/UNSCIENTIFIC poll:
>
> What *single* (non-traditional) language feature do you find most
> valuable in developing code?  (and, applicable language if unique to
> *a* language or class of languages)

The @ in various forms to tie a physical address to a symbolic variable.
This construct more that any other single thing allows many high level
languages have the ability broaden the range of potential applications
from high level to close to the machine.

It is language independent and very easy to add to compilers without
changing the basic form of the language.

w..

Walter Banks <walter@bytecraft.com> writes:
> The @ in various forms to tie a physical address to a symbolic variable.

Do you mean pointer variables, like *x in C?  

> It is language independent and very easy to add to compilers without
> changing the basic form of the language.

True in that the input programs can look about the same as before.  But
it can change the range of behaviours possible to the programs, making
them more flexible (maybe good) but less predictable (maybe bad).  So
it's a trade-off like lots of other things are.

On 3/7/2017 9:10 PM, Walter Banks wrote:
> On 2017-03-05 5:03 PM, Don Y wrote:
>> A quick/informal/UNSCIENTIFIC poll:
>>
>> What *single* (non-traditional) language feature do you find most
>> valuable in developing code?  (and, applicable language if unique to
>> *a* language or class of languages)
>
> The @ in various forms to tie a physical address to a symbolic variable.
> This construct more that any other single thing allows many high level
> languages have the ability broaden the range of potential applications
> from high level to close to the machine.

I assume you mean the "address of" operator?  I.e., "where is 'foo'?"

> It is language independent and very easy to add to compilers without
> changing the basic form of the language.

But, by itself, it is of little use.  So, you know *where* something is.
But, if you can't dereference the address (pointer), you can't affect
any changes to the environment around it (the pointer/referenced object).

[You can't *move* 'foo' though you could play games with pointer
arithmetic -- but, still impotent if you can't *do* anything with
those computed values!]

On 07/03/17 17:34, Don Y wrote:
> On 3/7/2017 4:24 AM, David Brown wrote:
>>> And, formed preferences for particular languages largely based on
>>> what the language allowed them to *do* -- and, at some fuzzy
>>> point in time, they thought to themselves:  "<previous_language> 
>>> wouldn't let me *do* things like this!"
>> 
>> Agreed (for people that have learned more than one language).
>> 
>> But what people view as "traditional features" is going to be
>> based almost totally on the languages they are most familiar with.
>> If you learned to program using Haskell, then you are going to
>> think in terms of lists, recursion, functions-of-functions, etc.
>> The idea of incrementing a variable or using a pointer would be
>> completely alien - but infinite lists are perfectly normal and
>> "traditional".  The opposite is true for someone programming in C.
> 
> That's entirely my point!  Should, instead, we argue over what 
> "traditional" means in the UNIVERSE of "programming" languages?
> *Then*, individually decide which features "stand out" as "valuable"
> in our own minds?

I am sorry, I am still having trouble trying to figure out what you are
asking for here.

Let's take a feature that I particularly like, and perhaps rate higher
than many others - static error checking (or compile-time warnings, if
you like).  I'm a big fan - I have lots of static_assert's in my code,
and use most of the warnings gcc or other compilers can give.

So do you want me to give you that as a "useful feature"?  Do you want
me to say it is "traditional" - after all, "lint" is almost as old as C.
 Do you want me to say is is "untraditional", given that many people
compiler there code without even bothering to use "-Wall", or they view
warnings as "just a warning that can be ignored"?

And as Wouter has been saying, it is not a feature that works in
isolation - the language has to support it, the tools have to support
it, implementations can have extensions to enhance it, and you have to
write your code in a way that gets the most out of it.

> 
> Or, do you let individuals come to grips with their own, personal
> notion of "traditional" and, from that, define their own sense of
> "utility"? ("*THIS* is what I think is really cool about THIS
> language...")

I don't really care what people think is "traditional" or not.  But
/you/ asked the question, asking for "non-traditional" features - /you/
have to define what you mean if you are going to get useful answers.

> 
> [Overloading operators in C++ to exploit infix notation can be "way 
> cool" to some as a more *expressive* way of writing code.  Others
> look past the syntax and see little changing in the *generated* code
> -- and yawn.]
> 
> I like the fact that I can write self-modifying code in languages
> that support pointers to code (not code whose behavior changes but,
> rather, CODE that changes -- leaving no sign of its ancestry).
> *Getting* that ability is an "oh, wow!" event.

On 08/03/17 05:10, Walter Banks wrote:
> On 2017-03-05 5:03 PM, Don Y wrote:
>> A quick/informal/UNSCIENTIFIC poll:
>>
>> What *single* (non-traditional) language feature do you find most
>> valuable in developing code?  (and, applicable language if unique to
>> *a* language or class of languages)
> 
> The @ in various forms to tie a physical address to a symbolic variable.
> This construct more that any other single thing allows many high level
> languages have the ability broaden the range of potential applications
> from high level to close to the machine.
> 
> It is language independent and very easy to add to compilers without
> changing the basic form of the language.
> 

Do you mean having a compiler extension for:

	volatile uint8_t REG @ 0x1234;

rather than the standard C:

	#define REG (*((volatile uint8_t*) 0x1234))

Certainly the "@" syntax is neater, and certainly it is nice if means
"REG" turns up in the linker map file and debugging data.  But it is
hardly a breakthrough, and does not allow anything that cannot be done
in normal C syntax just as efficiently (assuming the compiler
implementation is sane).

Most embedded compilers don't have anything equivalent to the "@" syntax
- yet people seem to manage to use them perfectly well for "close to the
machine" programming.

	

On 3/7/2017 3:29 PM, Wouter van Ooijen wrote:
> Op 07-Mar-17 om 18:31 schreef Don Y:
>> On 3/6/2017 12:04 AM, Wouter van Ooijen wrote:
>>> Op 06-Mar-17 om 00:03 schreef Don Y:
>>>> A quick/informal/UNSCIENTIFIC poll:
>>>>
>>>> What *single* (non-traditional) language feature do you find most
>>>> valuable in developing code?  (and, applicable language if unique
>>>> to *a* language or class of languages)
>>>
>>> I can't think of any language feature that is usefull in isolation.
>>
>> You, of course, wouldn't use *a* "single-feature language" for anything!
>>
>> OTOH, there are certain features of certain languages that are more
>> useful/valuable than other "features".
>
> IMO no. The most usefull feature of a language is that its features work well
> together.

So, you're saying that if I removed *any* one feature from ANY particular
language (of your chosing), the language would be USELESS?

Or, that if I were to enumerate all of the N "features" of a particular
language and then systematically remove just ONE of those features -- creating
N different versions of the language, in the process -- each would be equally
useful/useless languages, as contrasted to the original?

A "scientific calculator" is (for a certain class of applications) a more
useful tool than a "four function calculator".  What makes it so?  Which
feature ("function" in calculator-speak) added to a 4-function calculator
represents the biggest incremental value increase?  log?  ln?  y^x?  sqrt?

In a simpler scope, which of the features of the 4-function calculator
would you "miss" most if it were elided?  Would its removal render the
3-function calculator "useless"?

[Personally, I'd rate division as the "most valuable" feature to have on such
a calculator.  I can do multiplication, addition and subtraction with
relative ease.  But, division is *tedious* and far more error prone than
the other operations.  OTOH, the "feature" that I would miss, most, would
be "clear entry" -- as it allows me to correct typographical/keystroke errors
without having to reissue the entire computation sequence (as would be
required if I invoked "CLEAR")]

> I am a C++ fan, mainly because it enables me to do a lot at compile-time. But
> the C++ features that enables this were, especially pre-C++11, (templates)
> rather clumsy to use. C++14 constexptr is much better designed an mostly a joy
> to use (bit there are still a few rough edges).

So, you're admitting there are features of C++14 that are MORE useful than
"equivalent" features from C++11.

I.e., why aren't you STILL USING C++11??  You've decided (by your preference
for C++14) that there are BETTER features in C++14 vs. C++11.  So, you have
admitted that some features are "better" (more valuable) than others.  You
didn't abandon C++11 (prior to 2014) because it didn't have the features
of C++14!

> I am alos a Python fan, but certain aspects of the Python libraries make me
> sick, for instance the s.f() versus f( s ) variations, and the b = f( b )
> versus f( b ) confusions.
>
> These are examples of features that seem OK in isolation, but don't work well
> with other features. But if I'd have to mention a C++ feature, it is the
> ability to do things at compile time. But that more a concept realised by a
> number of features than a single language feature.

The "kitchen sink" approach seems common in newer languages.  Lots of syntactic
variations to achieve the same result.  Perhaps a wishy-washy attitude of
language designers (fear of taking an uncertain stance on an issue) *or* an
acknowledgement of the stylistic differences among developers and wanting to
accommodate all.

For "HLLs" (and pseudo-HLLs), there are few limits on what *can* be
added to the language's capabilities/features.  Machine languages obviously
impose more rigid limits (unless you have WCS support).

[Its instructive to examine some of the early/"true" RISC machines to see
what operations they considered "essential" -- worth implementing in silicon.
It's also worth examining how you would answer my query in *that* context;
do you decide something as "valuable" because it reduces code size, increases
execution speed *or* affords you a capability that you could not "emulate",
otherwise??]

On 08/03/17 10:49, Don Y wrote:
> On 3/7/2017 3:29 PM, Wouter van Ooijen wrote:
>> Op 07-Mar-17 om 18:31 schreef Don Y:
>>> On 3/6/2017 12:04 AM, Wouter van Ooijen wrote:
>>>> Op 06-Mar-17 om 00:03 schreef Don Y:
>>>>> A quick/informal/UNSCIENTIFIC poll:
>>>>>
>>>>> What *single* (non-traditional) language feature do you find most
>>>>> valuable in developing code?  (and, applicable language if unique
>>>>> to *a* language or class of languages)
>>>>
>>>> I can't think of any language feature that is usefull in isolation.
>>>
>>> You, of course, wouldn't use *a* "single-feature language" for anything!
>>>
>>> OTOH, there are certain features of certain languages that are more
>>> useful/valuable than other "features".
>>
>> IMO no. The most usefull feature of a language is that its features
>> work well
>> together.
> 
> So, you're saying that if I removed *any* one feature from ANY particular
> language (of your chosing), the language would be USELESS?
> 
> Or, that if I were to enumerate all of the N "features" of a particular
> language and then systematically remove just ONE of those features --
> creating
> N different versions of the language, in the process -- each would be
> equally
> useful/useless languages, as contrasted to the original?
> 
> A "scientific calculator" is (for a certain class of applications) a more
> useful tool than a "four function calculator".  What makes it so?  Which
> feature ("function" in calculator-speak) added to a 4-function calculator
> represents the biggest incremental value increase?  log?  ln?  y^x?  sqrt?
> 
> In a simpler scope, which of the features of the 4-function calculator
> would you "miss" most if it were elided?  Would its removal render the
> 3-function calculator "useless"?
> 
> [Personally, I'd rate division as the "most valuable" feature to have on
> such
> a calculator.  I can do multiplication, addition and subtraction with
> relative ease.  But, division is *tedious* and far more error prone than
> the other operations.  OTOH, the "feature" that I would miss, most, would
> be "clear entry" -- as it allows me to correct typographical/keystroke
> errors
> without having to reissue the entire computation sequence (as would be
> required if I invoked "CLEAR")]
> 
>> I am a C++ fan, mainly because it enables me to do a lot at
>> compile-time. But
>> the C++ features that enables this were, especially pre-C++11,
>> (templates)
>> rather clumsy to use. C++14 constexptr is much better designed an
>> mostly a joy
>> to use (bit there are still a few rough edges).
> 
> So, you're admitting there are features of C++14 that are MORE useful than
> "equivalent" features from C++11.
> 
> I.e., why aren't you STILL USING C++11??  You've decided (by your
> preference
> for C++14) that there are BETTER features in C++14 vs. C++11.  So, you have
> admitted that some features are "better" (more valuable) than others.  You
> didn't abandon C++11 (prior to 2014) because it didn't have the features
> of C++14!
> 

I can't answer for Wouter, but to me this sounds like you are trying to
make arguments for argument's sake.  What is so hard to understand about
someone using C++11 when that was well supported, but once C++14 was
common enough in tools, switching to C++14 to take advantage of useful
new features?  That does not mean that C++11 was the wrong language to
use previously, nor does it mean that there is /one/ new feature of
C++14 that makes it suddenly so much better than C++11.