paavo512 <paavo@osa.pri.ee> wrote or quoted:
|Anyway, multithreading performance is a non-issue for Python so far as
|the Python interpreter runs in a single-threaded regime anyway, under a |global GIL lock. They are planning to get rid of GIL, but this work is |still in development AFAIK. I'm sure it will take years to stabilize the |whole Python zoo without GIL.
The GIL only prevents multiple Python statements from being
interpreted simultaneously, but if you're waiting on inputs (like
sockets), it's not active, so that could be distributed across
multiple cores.
With asyncio, however, you can easily handle the application
for threads to "wait in parallel" for thousands of sockets in a
single thread, and there are fewer opportunities for errors than
with multithreading.
Additionally, there are libraries like numpy that use true
multithreading internally to distribute computational tasks
across multiple cores. By using such libraries, you can take
advantage of that. (Not to mention the AI libraries that have their
work done in highly parallel fashion by graphics cards.)
If you want real threads, you could probably work with Cython
sometimes.
Other languages like JavaScript seem to have an advantage there
because they don't know a GIL, but with JavaScript, for example,
it's because it always runs in a single thread overall. And in
the languages where there are threads without a GIL, you quickly
realize that programming correct non-trivial programs with
parallel processing is error-prone.
Just for waiting on thousands on sockets I believe a single select()
call would be sufficient ...
Am 29.04.2024 um 22:31 schrieb Lawrence D'Oliveiro:
On Mon, 29 Apr 2024 18:18:57 +0200, Bonita Montero wrote:
But you need multithreading to have maximum throughput since you often
process the data while other data is available.
In a lot of applications, the bottleneck is the network I/O, or a GUI
waiting for the next user event, that kind of thing. In this situation,
multithreading is more trouble than it’s worth. This is why coroutines
(in the form of async/await) have made a comeback over the last decade
or so.
Having a single thread and using state machines is more effortz.
On 29.04.2024 18:19, Stefan Ram wrote:
paavo512 <paavo@osa.pri.ee> wrote or quoted:
|Anyway, multithreading performance is a non-issue for Python so far as
|the Python interpreter runs in a single-threaded regime anyway, under a
|global GIL lock. They are planning to get rid of GIL, but this work is
|still in development AFAIK. I'm sure it will take years to stabilize the
|whole Python zoo without GIL.
The GIL only prevents multiple Python statements from being
interpreted simultaneously, but if you're waiting on inputs (like
sockets), it's not active, so that could be distributed across
multiple cores.
With asyncio, however, you can easily handle the application
for threads to "wait in parallel" for thousands of sockets in a
single thread, and there are fewer opportunities for errors than
with multithreading.
In C++, async io is provided e.g. by the asio library.
You don't need threads to get heisenbugs.
Am 29.04.2024 um 22:29 schrieb Lawrence D'Oliveiro:
We use poll(2) or epoll(2) nowadays. select(2) is antiquated.
Use Boost.ASIO.
So, the idea of the re-routine, is a sort of co-routine. That is, it
fits the definition of being a co-routine, though as with that when its asynchronous filling of the memo of its operation is unfulfilled, it
quits by throwing an exception, then is as expected to to called again,
when its filling of the memo is fulfilled, thus that it returns.
Am 02.05.2024 um 15:53 schrieb David Brown:
That is a /long/ way from treating functions as first-class objects.
A C-style function is also a function-object in C++ because it has
a calling operator.
But it is certainly a step in that direction, as are lambdas.
Lambdas can be assigned to function<>-object to make them runtime -polymorphic. Otherwise they can be generic types, which are compile
-time polymorphic - like the function-object for std::sort();
You also claimed that classes are first-class objects in C++.
I never said that and having sth. like class Class in Java is
beyond C++'s performance constraints.
Am 03.05.2024 um 09:38 schrieb David Brown:
No it is not. C-style functions (or C++ functions for that matter)
are not objects, and do not have calling operators. Built-in
operators do not belong to a type, in the way that class operators do.
You can assign a C-style function pointer to an auto function-object.
That these function objects all have the same type doesn't metter.
You missed the point entirely. Lambdas can be used in many ways like
functions, and it is possible for one function (or lambda) to return a
different function, and can be used for higher-order functions
(functions that have functions as parameters or return types). They
do not mean that C++ can treat functions as first-class objects, but
they /do/ mean that you can get many of the effects you might want if
C++ functions really were first-class objects.
C-style functions and lambda-types are generically interchangeable.
For C, I agree, mostly because C has no nested functions.
On Fri, 3 May 2024 17:20:00 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 03.05.2024 um 17:05 schrieb Michael S:
A typical scenario is that you started you python program while
thinking that it wouldn't e CPU-intensive. And then it grew and
became CPU-intensive.
That's actually a good case, because it means that your program is
used and is doing something worthwhile.
I don't think it makes a big difference if Python has a GIL or
not since it is interpreted and extremely slow with that anyway.
64 times faster than slow wouldn't be fast, but could be acceptable.
And 64 HW threads nowadays is almost low-end server, I have one at
work, just in case.
Also, I don't see why in the future Python could not be JITted.
Javascript was also considered slow 15-20 years ago, now it's pretty
fast.
But then, my knowledge of Python is very shallow, Possibly, it's not
JITted yet because of fundamental reasons rather than due to lack of
demand.
On Sat, 4 May 2024 00:27:53 +0100
bart <bc@freeuk.com> wrote:
On 03/05/2024 16:47, Michael S wrote:
On Fri, 3 May 2024 17:20:00 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 03.05.2024 um 17:05 schrieb Michael S:
A typical scenario is that you started you python program while
thinking that it wouldn't e CPU-intensive. And then it grew and
became CPU-intensive.
That's actually a good case, because it means that your program is
used and is doing something worthwhile.
I don't think it makes a big difference if Python has a GIL or
not since it is interpreted and extremely slow with that anyway.
64 times faster than slow wouldn't be fast, but could be acceptable.
And 64 HW threads nowadays is almost low-end server, I have one at
work, just in case.
Also, I don't see why in the future Python could not be JITted.
Javascript was also considered slow 15-20 years ago, now it's pretty
fast.
But then, my knowledge of Python is very shallow, Possibly, it's not
JITted yet because of fundamental reasons rather than due to lack of
demand.
PyPy has been around for many years.
I see.
So, why PyPy didn't replace interpreter as a default engine?
On 04.05.2024 01:20, Lawrence D'Oliveiro wrote:
On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote:
For C, I agree, mostly because C has no nested functions.
GCC implements nested functions in the C compiler. Though oddly, not in C+ >> +.
C++ already has functions nested in namespaces, namespaces nested in namespaces, functions nested in classes (static and non-static
member functions), and classes nested in classes. It's already a
lot of nesting, no need to complicate the matters more.
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 04.05.2024 01:20, Lawrence D'Oliveiro wrote:
On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote:
For C, I agree, mostly because C has no nested functions.
GCC implements nested functions in the C compiler. Though oddly, not in C+ >>> +.
C++ already has functions nested in namespaces, namespaces nested in
namespaces, functions nested in classes (static and non-static
member functions), and classes nested in classes. It's already a
lot of nesting, no need to complicate the matters more.
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
As a code reader, I very much prefer C, where nested function are not
allowed at all.
On Sun, 5 May 2024 12:37:18 +0300, Michael S wrote:
As a code reader, I very much prefer C, where nested function are
not allowed at all.
The GNU C compiler allows them: see my example in the “Recursion, Yo” thread.
On 07.05.2024 01:13, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 04.05.2024 01:20, Lawrence D'Oliveiro wrote:
On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote:
For C, I agree, mostly because C has no nested functions.
GCC implements nested functions in the C compiler. Though
oddly, not in C++.
C++ already has functions nested in namespaces, namespaces nested in
namespaces, functions nested in classes (static and non-static
member functions), and classes nested in classes. It's already a
lot of nesting, no need to complicate the matters more.
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly
which variables are shared and how. One can be lazy and pass [&], but
one doesn't have to.
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly
which variables are shared and how. One can be lazy and pass [&], but
one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
On Tue, 2024-05-14 at 13:53 +0300, Paavo Helde wrote:
On 14.05.2024 05:43, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly >>>> which variables are shared and how. One can be lazy and pass [&], but >>>> one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar. For just
writing Turing complete code one programming language would be enough.
The primary goal of high level language should be for reducing software development/maintenance cost.
Cpp is just having too many 'syntactic sugars'
(and keep on adding it) to be away from this goal, IMO.
Putting the 'expressivness' aside, I think cpp cannot complete with C and Assembly if measuring the compiled code size and speed. But I still like to program in cpp for my own reasons.
On Tue, 2024-05-14 at 16:24 +0200, David Brown wrote:
So Tim is completely wrong to say that specifying the variables
accessible in a lambda gives "no real advantages". It doesn't give the
compiler's code /generator/ any more information than it can deduce
itself from [&] or [=], but it gives more information to the compiler's
code /checker/ and to human programmers - those are big advantages and
greater expressive power.
Probably. I now still hesitate whether or not I should learn and adopt C++'s lambda expression. My consideration is that many new features after C++11
are not really necessary and the burden may be greater than the gain for me.
Cpp is just having too many 'syntactic sugars'
(and keep on adding it) to be away from this goal, IMO.
C++ is a very big language, and gains new features (in the language and
standard library) every three years. While some features make it easier
to write better code, backwards compatibility means it is rarely
possible to remove features that are no longer necessary. Thus if you
want to be able to read and understand all the syntax of C++, it gets
more effort. But if you are in the position to be able to deal with C++
code using only the features you find useful and like, then that is much
less of an issue.
I am not optimistic about the future of C++.
It is perhaps easier to accidentally write code that is big and slow in
C++ than it is in C, but it is certainly not necessary.
My concern is that C++ codes typically consumes more memory much less proportional than the speed gain. Basically, time*space=constant, which is especially observable for computation intensive problems. I am more concerned about the cost of problem solving instead of plain code analysis.
And while it occasionally makes sense to use assembly for the most
time-critical parts of code, it is very common for clear, maintainable C
or C++ code to be /faster/ than clear, maintainable assembly code.
Unless you are dealing with something that makes use of processor
instructions or features that are unknown to the C/C++ compiler, writing
assembly code that is faster than C or C++ will often require such
specific care for things like instruction scheduling, register pressure,
cache prefetching, etc., than your results will be far from clear or
maintainable. And by the time you've got it working, the end user has
bought a new PC and the processor has different numbers of execution
units and more specialised instructions. You can re-write much of the
assembly, or you can re-compile your C/C++ with a different "-march=" flag.
To me, there is no clear cut saying which (assembly or C/C++) is better just from the view point of common capabilities mutual to low/high level languages.
(there are many capabilities C/C++ cannot do, typically involving hardware capabilities, virus, anti-interference, simulation,...)
It all depends on what kind of application is desired.
Generally, I feel software projects within 6-man-month are no difference from the language choice. One can also program assembly as fast.
Those said, I retired earily (at about 37), I use C++ exclusively since then. Many are from my memory and what I received and my observations.
On Tue, 2024-05-14 at 23:34 +0300, Paavo Helde wrote:
Guess what? Nobody in the team wanted to learn Linux, ARM and x86_64
assemblers just for porting these small pieces of an existing program.
The pieces were rewritten in C++ and the original assembler code was
promptly forgotten. Good riddance!
Who would use assembly and consider porting to different, incompatible CPU/platforms?
What is the real meaning of 'porting'? I think a C/C++ program for Window using
its specific libraries is not easily ported to Linux where that libraries are not
available. This kind of task is usually not really 'porting'.
Assembly has its bads, but considering the fact that writting assembly is basically the same as writting high level language except the compilation is done by human instead of automated by the compilation tools.
The number of lines of assembly program is usually several times longer than high level language. But that is just appearance, the complexity is the same. Many of the extra works can be mechanically (or the like) solved.
On Tue, 2024-05-14 at 16:24 +0200, David Brown wrote:
On 14/05/2024 13:46, wij wrote:
On Tue, 2024-05-14 at 13:53 +0300, Paavo Helde wrote:
On 14.05.2024 05:43, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly >>>>>> which variables are shared and how. One can be lazy and pass [&], but >>>>>> one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar. For just
writing Turing complete code one programming language would be enough. >>>>
The primary goal of high level language should be for reducing software
development/maintenance cost.
Yes. And the main way to do that is to reduce the risk of errors
passing into later stages of development. A language (and the
programmer using the language) should aim to make it easy to write good
code, hard to write bad code, easy to see that good code is good, and
easy to see that bad code is bad.
Sounds like Bjarne Stroustrup's tongue.
But I don't feel C++ is steering
in that way. Since C++11 many features do not feel like what BS says in his book.
"Syntactic sugar" is vital to this effort. And a key source of "power"
of a language is not in what it allows you do to, but in what it stops
you from doing, or allows you to restrict yourself. For example, often
a correct program will work just as correctly, and just as efficiently,
if all uses of "const" are removed. The "const" does not add to the
things the language can do - it helps by restricting the errors you can
make when using the language.
I agree what you say, but pretty much every high level language would say
the same (how about BASIC?).
I am more concerned about the practical side.
So Tim is completely wrong to say that specifying the variables
accessible in a lambda gives "no real advantages". It doesn't give the
compiler's code /generator/ any more information than it can deduce
itself from [&] or [=], but it gives more information to the compiler's
code /checker/ and to human programmers - those are big advantages and
greater expressive power.
Probably. I now still hesitate whether or not I should learn and adopt C++'s lambda expression. My consideration is that many new features after C++11
are not really necessary and the burden may be greater than the gain for me.
Cpp is just having too many 'syntactic sugars'
(and keep on adding it) to be away from this goal, IMO.
C++ is a very big language, and gains new features (in the language and
standard library) every three years. While some features make it easier
to write better code, backwards compatibility means it is rarely
possible to remove features that are no longer necessary. Thus if you
want to be able to read and understand all the syntax of C++, it gets
more effort. But if you are in the position to be able to deal with C++
code using only the features you find useful and like, then that is much
less of an issue.
I am not optimistic about the future of C++.
It's primarily when dealing with smart-arse
programmers like Bonita that it is a real problem. (But such
programmers can also write smart-arse code in C and any other language
they use.)
Putting the 'expressivness' aside, I think cpp cannot complete with C and >>> Assembly if measuring the compiled code size and speed. But I still like to >>> program in cpp for my own reasons.
If your C++ code is more than marginally slower than equivalent C code
in situations where the speed is important, then you are using C++
incorrectly. It's not uncommon for C++ to pull in a whole lot of extra
library code, but that is rarely significant on PC's or other "big"
computers.
It is perhaps easier to accidentally write code that is big and slow in
C++ than it is in C, but it is certainly not necessary.
My concern is that C++ codes typically consumes more memory much less proportional than the speed gain.
Basically, time*space=constant,
which is
especially observable for computation intensive problems. I am more concerned about the cost of problem solving instead of plain code analysis.
And while it occasionally makes sense to use assembly for the most
time-critical parts of code, it is very common for clear, maintainable C
or C++ code to be /faster/ than clear, maintainable assembly code.
Unless you are dealing with something that makes use of processor
instructions or features that are unknown to the C/C++ compiler, writing
assembly code that is faster than C or C++ will often require such
specific care for things like instruction scheduling, register pressure,
cache prefetching, etc., than your results will be far from clear or
maintainable. And by the time you've got it working, the end user has
bought a new PC and the processor has different numbers of execution
units and more specialised instructions. You can re-write much of the
assembly, or you can re-compile your C/C++ with a different "-march=" flag.
To me, there is no clear cut saying which (assembly or C/C++) is better just from the view point of common capabilities mutual to low/high level languages.
(there are many capabilities C/C++ cannot do, typically involving hardware capabilities, virus, anti-interference, simulation,...)
It all depends on what kind of application is desired.
Generally, I feel software projects within 6-man-month are no difference from the language choice. One can also program assembly as fast.
Those said, I retired earily (at about 37), I use C++ exclusively since then. Many are from my memory and what I received and my observations.
On 14.05.2024 05:43, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify
explicitly which variables are shared and how. One can be lazy
and pass [&], but one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar. For just
writing Turing complete code one programming language would be enough.
You are right in your concern, C++ language does not particularly consume more
run-time memory than C. I was concerned about the abuse of container classes. std::list is mostly the case. For others, I should say those 'data structure' containing links, e.g. std::set. Because the ratio of speed gain and memory consumption is likely very low. C++ programmer should notice this point.
Am 14.05.2024 um 22:34 schrieb Paavo Helde:
endpoints.erase(std::remove_if(endpoints.begin(), endpoints.end(),
[](auto endpoint) {return !endpoint->datagram();}),
endpoints.end());
Better auto &endpoint.
On Mon, 13 May 2024 00:43:38 -0000 (UTC) Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:
On Sun, 5 May 2024 12:37:18 +0300, Michael S wrote:
As a code reader, I very much prefer C, where nested function are not
allowed at all.
The GNU C compiler allows them: see my example in the “Recursion, Yo”
thread.
Which does not make it legal C. Or good ideea.
Am 14.05.2024 um 04:43 schrieb Tim Rentsch:
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Lambdas can reduce a lot of redundant code. [...]
On 15.05.2024 03:31, wij wrote:[...]
Assembly has its bads, but considering the fact that writting
assembly is basically the same as writting high level language
except the compilation is done by human instead of automated by
the compilation tools. [...]
To be honest, I am a bit baffled we are having this kind of
conversation so far into the 21-st century.
On Tue, 14 May 2024 13:53:02 +0300[comparing lambdas and nested functions]
Paavo Helde <eesnimi@osa.pri.ee> wrote:
On 14.05.2024 05:43, Tim Rentsch wrote:
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar. For
just writing Turing complete code one programming language would
be enough.
As far as I am concerned, the two most important thing that
programming languages do are:
1 - helping programmer to not repeat himself
2 - automation of common tasks, which is also sort helping
programmer to not repeat, but in this case to not repeat somebody
else rather than himself
These two are nutrients. The reset is sugar that can or can not
improve productivity during later phases of maintenance, but does
nothing to improve productivity during initial development and
debugging. You can be right that sugar constitutes the bulk of
the volume of programming language, but it does not make it more
important than vital things.
On 14.05.2024 05:43, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly
which variables are shared and how. One can be lazy and pass [&], but
one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar.
For just writing Turing complete code one programming language
would be enough.
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 14.05.2024 05:43, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly >>>> which variables are shared and how. One can be lazy and pass [&], but >>>> one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar.
You must mean something different by "syntactic sugar" than I
do.
For just writing Turing complete code one programming language
would be enough.
That statement is true but irrelevant. C++ and PostScript
are both Turing complete, but it's absurd to suggest that
there are no significant differences between them.
On 22.05.2024 06:27, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 14.05.2024 05:43, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly >>>>> which variables are shared and how. One can be lazy and pass [&], but >>>>> one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar.
You must mean something different by "syntactic sugar" than I
do.
Just to clarify, for example many programming languages have syntax
for defining functions or subroutines, which IMO can be viewed as
syntactic sugar over JMP/GOTO which could be used instead.
What the heck, even having named variables is syntactic sugar over
numeric memory slots. I recall the programs written for programmable calculators in 1980-s did not provide such a luxury as variable names.
For just writing Turing complete code one programming language
would be enough.
That statement is true but irrelevant. C++ and PostScript
are both Turing complete, but it's absurd to suggest that
there are no significant differences between them.
Absolutely agree, and most what makes them different is syntactic
sugar.
Adding numbers happens by the same CPU operations both in C++ and
PostScript, but there is an enormous difference in how one has to
write the orders to get these numbers added.
On Tue, 2024-05-14 at 16:24 +0200, David Brown wrote:
On 14/05/2024 13:46, wij wrote:
On Tue, 2024-05-14 at 13:53 +0300, Paavo Helde wrote:
On 14.05.2024 05:43, Tim Rentsch wrote:
Paavo Helde <eesnimi@osa.pri.ee> writes:
On 07.05.2024 01:13, Tim Rentsch wrote:
C++ doesn't need nested functions because it has lambdas, which
are effectively equivalent.
Lambdas are better than nested functions as one can specify explicitly >>>>>> which variables are shared and how. One can be lazy and pass [&], but >>>>>> one doesn't have to.
To me that sounds like all the complications of nested functions,
and more besides, and no real advantages. The choice of which
variables to share is syntactic sugar, there is no difference
in expressive power.
Most of what programming languages do is syntactic sugar. For just
writing Turing complete code one programming language would be enough.
The primary goal of high level language should be for reducing software
development/maintenance cost.
Yes. And the main way to do that is to reduce the risk of errors
passing into later stages of development. A language (and the
programmer using the language) should aim to make it easy to write good
code, hard to write bad code, easy to see that good code is good, and
easy to see that bad code is bad.
Sounds like Bjarne Stroustrup's tongue. But I don't feel C++ is steering
in that way. Since C++11 many features do not feel like what BS says in his book.
"Syntactic sugar" is vital to this effort. And a key source of "power"
of a language is not in what it allows you do to, but in what it stops
you from doing, or allows you to restrict yourself. For example, often
a correct program will work just as correctly, and just as efficiently,
if all uses of "const" are removed. The "const" does not add to the
things the language can do - it helps by restricting the errors you can
make when using the language.
I agree what you say, but pretty much every high level language would say
the same (how about BASIC?). I am more concerned about the practical side.
So Tim is completely wrong to say that specifying the variables
accessible in a lambda gives "no real advantages". It doesn't give the
compiler's code /generator/ any more information than it can deduce
itself from [&] or [=], but it gives more information to the compiler's
code /checker/ and to human programmers - those are big advantages and
greater expressive power.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:13:33 |
| Calls: | 6,910 |
| Files: | 12,376 |
| Messages: | 5,429,289 |