The Big Programming Thread - Page 573

On January 29 2015 04:04 darkness wrote:


Well, I've recently started learning C++ and I can say it looks safer so far. Provided that you use the right tools, of course.

Edit: C's macros immediately come to mind.

I'm also not saying C++ is completely safe, it obviously has a lot of undefined behaviour (e.g. dangling raw pointers) but I think it's safer than C.

*hidden complexity*
(1) it's hard to say what code will compile down to. viz., constructors can
be elided, but there is no fitness warranty; profiling your compiler to find out
whether it is elided is tedious and "searching for secrets" that should be
_explicit_
(2) people don't understand static polymorphism and compile-time dispatch;
people are used to objects sending messages dynamically (run-time dispatch)
(3) coercion
(4) networks of objects are not explicitly laid out, hiding quadratically
complex patterns of communication between objects
(5) data structure and data flow come before algorithms. Sometimes, data
structure dictates data flow (ad-hoc networks of objects); sometimes, data flow
dictates data structure (one of life's most disagreeable tasks - waiting in line
- is characterized as FIFO). This, I feel, is the most important point, because
the first rule of programming is to figure out what you want to say before you
figure out how to say it. In C++, ad-hoc networks of objects with cyclic
message paths are all too easy to create [see (4)] which means _code_ _is_ _not_
_explicit_ and as a result _code_ _is_ _not_ _fast_.

*transfer semantics on objects are not robust*
this ties into (1) in hidden complexity
the code author needs to specify a lot of boilerplate to achieve desired
transfer semantics on objects. Similarly, the code audience, be it reviewer,
maintainer or merger, needs to read a lot of boilerplate to understand how
objects get moved around in memory. Moreover, most of these concepts are
intuitively declarative in nature, such as a parent object/child object relation.

*poor re-use of effort*
"code re-use" is a misnomer; when programmers speak of code-reuse they mean
re-use of effort. There is no benefit to polymorphism if effort cannot be
consolidated easily.

*C++ Standard iffy*
Some things just disappear quickly for *frantic* reasons (strstream was
removed for aesthetics), indicating not enough foresight into what is important.
I do not want to pick a language where I have to worry about features in it's
"standard library" becoming deprecated mainly for aesthetics. As Dijkstra
preached, programming is _not_ supposed to be a frantic exercise.

--
Z-Bo

[...]
The problem with C++ is that every C++ developer has his own style,
and reuse is an illusion within that style. Take a look at classes
implementing matrix arithmetic: there are as many around as the day is
long, and all of them are incompatible with one another.

With regard to programming styles, C++ does not support multiple
inheritance. For a single project grown from a single start, you can
get reasonable solutions. But combining stuff is creating maintenance
messes.

With C, the situation is not dissimilar, but you spent less time
fighting the illusion that you don't need to reimplement, anyway.

The difference is that you can pass structures from one library into
another with tolerable efficiency. Because there are only basically 2
ways to lay out a two-dimensional array of floats.
[...]

Care to explain why there are still not two numerical C++ libraries
with compatible matrix classes?

What use is talking about portability and high level when a basic
interoperability feature that has been available since the sixties
(more than 4 decades ago) in Fortran has not yet managed to make it
into C++? C++ by now more or less offers a (somewhat deficient)
standardized way to work with complex numbers, but matrices are still
not standardized in any manner, and libraries won't interoperate.

So C++ should get its head wrapped around the _low_ level problems
first. It is a bloody shame that it still has not caught up with
Fortran IV (or even Fortran II) with regard to usefulness for
numerical libraries.

It is not a matter of "hating high level" to see that C++ is mostly
focused about addressing the wrong kinds of problems in the wrong
ways. The pain/gain ratio is just bad.
[...]

Making a language huge and bloated in order to be able to use the
language itself for defining a set of basic data types is just
masturbation. C++ has the most complicated set of implicit
conversions from any language in the world, and what for? It is
modeled for being able to create a user-defined "complex" type which
behaves almost as well as Fortran's. Too bad that this mostly means
everybody will define his own type (well, at least we have seen two or
three different library "standards" by now), and that the implicit
conversion rules and chains are appallingly wrong for a number of
other possible user-defined arithmetic types.

--
David Kastrup

On January 29 2015 05:50 BlueRoyaL wrote:
Question for you guys coming from someone that does mainly webdev and .NET stuff.

I'm looking to create some mobile app (ideally and eventually for both the Android and iOS markets).

Is my understanding that for Android you use Java and for iOS either swift or objective-c correct?

If I have a choice between learning swift versus objective-c, which would you say is the better path?

And any generally recommendations for a newbie wanting to learn mobile app development would be pretty sweet!

On January 29 2015 06:05 darkness wrote:
Even with a Computer Science degree, I cannot appreciate Dijkstra's programming views, so I can only sympathise with ill souls who believe and quote him. That said, he is right about goto's but that's it. <snip generic stuff about languages>

On January 29 2015 06:38 bangsholt wrote:


You disagree with his programming views?

I mean, as an example, the goto paper is about using structured programming instead of using goto as control structures, to make code easier to write and to debug because you won't be jumping all over the place ^_^

Or do you dislike his algorithms? I really don't follow what you mean :D

Object-oriented programming is an exceptionally bad idea which could only have originated in California.
-Edsger Dijkstra

On January 29 2015 06:26 nunez wrote:
@manitou
your ignorance will always reveal itself
when you attempt to give insights into
a language you know little about.

try to keep it constructive, and
focus on the languages you know and like.

Object-oriented programming is an exceptionally bad idea which could only have originated in California.
-Edsger Dijkstra

On January 29 2015 06:15 Blisse wrote:
Swift because Objective-C is going to be outdated. Unless you need to release in the next 3 months, no point in learning that mess.

On January 29 2015 13:27 ZenithM wrote:
I never can't know if nunez is trying to write poetry or if he's just writing TL posts with emacs.