www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [article] Language Design Deal Breakers

reply =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
I think this have not been posted yet around here but might be interesting
to the D community as it is actually criticizing several languages
including D but with an interesting aproach:

http://sebastiansylvan.wordpress.com/2013/05/25/language-design-deal-breakers/

Joel Lamotte
May 25 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 26 May 2013 00:50:28 +0200
Klaim - Jo=C3=ABl Lamotte <mjklaim gmail.com> wrote:

 I think this have not been posted yet around here but might be
 interesting to the D community as it is actually criticizing several
 languages including D but with an interesting aproach:
=20
 http://sebastiansylvan.wordpress.com/2013/05/25/language-design-deal-brea=


kers/

=20


Hah, now that's my kind of dude:

"I know you=E2=80=99re supposed to be diplomatic and claim that there=E2=80=
=99s two
sides to this story, and no real right answer, but really people who
think dynamic typing is suitable for large scale software development
are just nuts. They=E2=80=99ll claim it=E2=80=99s more flexible and general=
 but that=E2=80=99s
just nonsense in my opinion."

Classic :) It's weird when I see my thoughts written by someone else
(and worded better that I would have), but he nailed it there.

I do think his "inertia" with C++ is cranked way into overdrive,
though. Forget waiting for a huge improvement, I'd have been happy to
ditch C++ even for a small improvement. C++ is such a pain IMO that
using it has about as much inertia as ice skates on concrete.

Still though, great article.

He has another great bit in a different article that one links to:


and the current trend of writing apps in HTML5 and JavaScript and then
running it on top of some browser-like environment is positively
bonkers. The proliferation of abstraction layers and general =E2=80=9Ccruft=
=E2=80=9D is
a huge pet peeve of mine =E2=80=93 I don=E2=80=99t understand why it takes =
30 seconds
to launch a glorified text editor (like most IDEs =E2=80=93 Eclipse, Visual
Studio, etc.), when it took a fraction of a second twenty years ago on
hardware that was thousands of times slower."
-
http://sebastiansylvan.wordpress.com/2013/04/18/on-gc-in-games-response-to-=
jeff-and-casey/


performance games" langauge, I *do* definitely understand the game
industry's increasing usage of it considering that aside from D (which
still isn't quite ready-to-use on most gaming platforms) their only
other real alternative is C++.
May 25 2013
next sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 26/05/13 11:59, Nick Sabalausky wrote:

 On Sun, 26 May 2013 00:50:28 +0200
 Klaim - Joël Lamotte <mjklaim gmail.com> wrote:

 I think this have not been posted yet around here but might be
 interesting to the D community as it is actually criticizing several
 languages including D but with an interesting aproach:

 http://sebastiansylvan.wordpress.com/2013/05/25/language-design-deal-breakers/


 Hah, now that's my kind of dude:

 "I know you’re supposed to be diplomatic and claim that there’s two
 sides to this story, and no real right answer, but really people who
 think dynamic typing is suitable for large scale software development
 are just nuts. They’ll claim it’s more flexible and general but that’s
 just nonsense in my opinion."

 Classic :) It's weird when I see my thoughts written by someone else
 (and worded better that I would have), but he nailed it there.

 I do think his "inertia" with C++ is cranked way into overdrive,
 though.


Yes.


 Forget waiting for a huge improvement, I'd have been happy to
 ditch C++ even for a small improvement. C++ is such a pain IMO that
 using it has about as much inertia as ice skates on concrete.


I found shifting from C++ to C an improvement.  (Yes, I learnt C++ 
before I learnt C.)  I should mention that this was back in the mid 90s 
and C++ may have improved since then :-).

Peter
May 25 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 26.05.2013 05:27, schrieb Peter Williams:

 On 26/05/13 11:59, Nick Sabalausky wrote:



 Forget waiting for a huge improvement, I'd have been happy to
 ditch C++ even for a small improvement. C++ is such a pain IMO that
 using it has about as much inertia as ice skates on concrete.


 I found shifting from C++ to C an improvement.  (Yes, I learnt C++
 before I learnt C.)  I should mention that this was back in the mid 90s
 and C++ may have improved since then :-).

 Peter


After being a Turbo Pascal heavy user, C always felt backwards to me 
with its weak types, lack of proper strings, modules and namespaces.

Even with its warts C++ offers a more cosy environment in terms of 
strong typing, modularity and abstractions to use, at least to me.

I am a strong supporter of Microsoft's decision to dump C from their 
tooling. Only with such actions can a system programming language be 
eventually replaced.


--
Paulo
May 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/26/2013 12:03 AM, Paulo Pinto wrote:

 After being a Turbo Pascal heavy user, C always felt backwards to me with its
 weak types, lack of proper strings, modules and namespaces.


I had the opposite experience. Being a Pascal user from the late 70's, I hated 
Pascal's limitations. A friend loaned me K+R and it was like someone opened a 
window. I never wrote another line of Pascal; I threw it under the bus, and 
couldn't work up any interest in TP (which came along later).

Proper strings? Those length-prefixed ones that couldn't be longer than 255 
characters? Argh. C botched them too with 0 terminated ones, but at least they 
were usable.
May 26 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 26.05.2013 09:36, schrieb Walter Bright:

 On 5/26/2013 12:03 AM, Paulo Pinto wrote:

 After being a Turbo Pascal heavy user, C always felt backwards to me
 with its
 weak types, lack of proper strings, modules and namespaces.


 I had the opposite experience. Being a Pascal user from the late 70's, I
 hated Pascal's limitations. A friend loaned me K+R and it was like
 someone opened a window. I never wrote another line of Pascal; I threw
 it under the bus, and couldn't work up any interest in TP (which came
 along later).

 Proper strings? Those length-prefixed ones that couldn't be longer than
 255 characters? Argh. C botched them too with 0 terminated ones, but at
 least they were usable.


Pascal string limitations were only an issue in classic Pascal, both 
Extend Pascal its sucessors Modula-2 and so on follow a model similar to 
what D offers.

Now it is too late for it, but at the time C could have stayed as 
powerful as it is while offering:

- proper modules, or at least namespaces

- no automatic conversions between arrays and pointers. how hard it is 
to write &a[0]?

- arguments by reference, no need to check for null for every parameter

- strong typed enumerations

- memory allocation without requiring the developer to use sizeof everywhere

- strings similar to what D has

- proper arrays, after all the compilers for other languages always 
offered control over when bound checking code was generated

In the end, same syntax, just some semantic improvements on the type system.

But now it is too late, we only have modern C++ with its warts, or 


However, given that C and UNIX are one and only, it will outlive us all.

--
Paulo
May 26 2013
parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 26/05/13 21:13, Paulo Pinto wrote:

 Am 26.05.2013 09:36, schrieb Walter Bright:

 On 5/26/2013 12:03 AM, Paulo Pinto wrote:

 After being a Turbo Pascal heavy user, C always felt backwards to me
 with its
 weak types, lack of proper strings, modules and namespaces.


 I had the opposite experience. Being a Pascal user from the late 70's, I
 hated Pascal's limitations. A friend loaned me K+R and it was like
 someone opened a window. I never wrote another line of Pascal; I threw
 it under the bus, and couldn't work up any interest in TP (which came
 along later).

 Proper strings? Those length-prefixed ones that couldn't be longer than
 255 characters? Argh. C botched them too with 0 terminated ones, but at
 least they were usable.


 Pascal string limitations were only an issue in classic Pascal, both
 Extend Pascal its sucessors Modula-2 and so on follow a model similar to
 what D offers.

 Now it is too late for it, but at the time C could have stayed as
 powerful as it is while offering:

 - proper modules, or at least namespaces

 - no automatic conversions between arrays and pointers. how hard it is
 to write &a[0]?

 - arguments by reference, no need to check for null for every parameter

 - strong typed enumerations

 - memory allocation without requiring the developer to use sizeof
 everywhere

 - strings similar to what D has

 - proper arrays, after all the compilers for other languages always
 offered control over when bound checking code was generated

 In the end, same syntax, just some semantic improvements on the type
 system.

 But now it is too late, we only have modern C++ with its warts, or


 However, given that C and UNIX are one and only, it will outlive us all.


Don't forget that Pascal was only meant to be a teaching language.  That 
it was used for more than that says more about the other languages 
available at the time than it does Pascal.

Peter
May 26 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 26 May 2013 13:27:55 +1000
Peter Williams <pwil3058 bigpond.net.au> wrote:

 
 I should mention that this was back in the mid
 90s and C++ may have improved since then :-).
 


I dunno. The more I learned about C++'s more advances features the more
disillusioned I became with it. I was always happiest (or at least,
least unhappy) with the "C with classes" form of C++.

But then again, maybe that has nothing to do with "older C++ vs newer
C++"?
May 26 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 26, 2013 at 01:27:55PM +1000, Peter Williams wrote:

 On 26/05/13 11:59, Nick Sabalausky wrote:


[...]

Forget waiting for a huge improvement, I'd have been happy to
ditch C++ even for a small improvement. C++ is such a pain IMO that
using it has about as much inertia as ice skates on concrete.


 
 I found shifting from C++ to C an improvement.  (Yes, I learnt C++
 before I learnt C.)  I should mention that this was back in the mid
 90s and C++ may have improved since then :-).


[...]

You're not the only one who felt that way. At my day job we also
"upgraded" from C++ back to C. I've often ranted about our horrific
experience with a hugely over-engineered C++ system that can literally
do *anything*... except that nobody understood how to use the thing. It
had dtors with side-effects that did useful work, for instance, and
there were so many levels of abstraction it was bordering on insanity.
Once I had to make a function call to said horrible code... it involved
going through 6 layers of abstraction, two of which were fwrite()ing
function arguments to a temporary file, then fork() and exec()ing an
auxilliary utility that fread() the arguments back, and *then*
dispatched them across an IPC link...

We're now back in C-land, and boy the code is much cleaner, and
*faster*, even though it's a lot harder to read and more tedious to
maintain.

Like I've said many times before, the only way I found coding in C++
tolerable was to use it as "C with classes". Trying to do real OO in C++
is an exercise in masochism. Even Java with its baroque verbosity and
prolific boilerplates beats C++ hands-down in this respect. And don't
even mention templates, which are already nasty enough to work with in
simple generic types; they are utter monstrosities when you start
getting into CTFE and compile-time codegen. D templates, CTFE, and
mixins, by contrast, are actually *pleasant* to work with.


T

-- 
Computers shouldn't beep through the keyhole.
May 25 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 25 May 2013 22:44:52 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 
 Like I've said many times before, the only way I found coding in C++
 tolerable was to use it as "C with classes". Trying to do real OO in
 C++ is an exercise in masochism. Even Java with its baroque verbosity
 and prolific boilerplates beats C++ hands-down in this respect. 
 


I always used to consider myself comfortable with C/C++ until I came
across Java.

To mix metaphors, that was a double-edged eye-opener: Java (this was
circa v1.2-v1.4) taught me everything that was wrong with C++'s classes
and *cough* module system, but it *also* taught me that Java wasn't
the answer either. ;)
May 26 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 26.05.2013 11:28, schrieb Nick Sabalausky:

 On Sat, 25 May 2013 22:44:52 -0700
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 Like I've said many times before, the only way I found coding in C++
 tolerable was to use it as "C with classes". Trying to do real OO in
 C++ is an exercise in masochism. Even Java with its baroque verbosity
 and prolific boilerplates beats C++ hands-down in this respect.


 I always used to consider myself comfortable with C/C++ until I came
 across Java.

 To mix metaphors, that was a double-edged eye-opener: Java (this was
 circa v1.2-v1.4) taught me everything that was wrong with C++'s classes
 and *cough* module system, but it *also* taught me that Java wasn't
 the answer either. ;)


For me the deal break was that it worked more or less the same 
everywhere, while keeping a C++ feeling.

Plus it had a module system reminiscent of Pascal family of languages, 
and back then I was already impressed with GC enabled systems 
programming languages thanks to Native Oberon operating system.

Did you had the pleasure to write portable C or C++ code across multiple 
operating systems and vendors in the mid 90's?

Welcome to #ifdef spaghetti code and reluctance of using certain 
features due to inconsistent support.

--
Paulo
May 26 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 26, 2013 at 01:18:32PM +0200, Paulo Pinto wrote:
[...]

 Did you had the pleasure to write portable C or C++ code across
 multiple operating systems and vendors in the mid 90's?
 
 Welcome to #ifdef spaghetti code and reluctance of using certain
 features due to inconsistent support.


[...]

Ugh! Don't remind me. Right now at work I have a project that requires
reading (yes, just reading) some heavily #ifdef'd code. It's a very,
very, very painful experience.

Not to mention function pointer spaghetti. One of the symptoms of
switching from C++ back to C is that there's no polymorphic abstraction
anymore, so the only way to have a sane polymorphic system is to use
tables of function pointers everywhere. When a bug happens in some
obscure corner of the code, it's hours and hours of hair-pulling to
discover just which of 50 different function pointer initializations
were in effect when the bug happened, for each of the 50 function
pointers traversed before the buggy code. It's gotten to the point that
every other line of code is a call through a function pointer, each of
which has its own set of 50 or so different functions that it can
potentially point to. It doesn't help that many of these function
pointers are unhelpfully named. I'm quite near the point of losing my
sanity just trying to figure out the control flow of the thing!

Ah, if only this code were written in D... :-P


T

-- 
What doesn't kill me makes me stranger.
May 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/26/2013 7:48 AM, H. S. Teoh wrote:

 Ah, if only this code were written in D... :-P


One possibility is to write the code in D, debug it, then recode the result in
C 
to satisfy your customer.

(Don't dismiss this out of hand - I've seen this sort of thing done before.
Back 
when I was programming hand-held LED games for Mattel (remember those?) the 
prototype was written for a 6502 single board computer that fit in a Samsonite 
briefcase. Once the gameplay and everything else was massaged to perfection, it 
was handed over to another group of engineers who translated it to work on the
4 
bit computer that drove the actual handheld device.)
May 26 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 26 May 2013 11:51:24 -0700
Walter Bright <newshound2 digitalmars.com> wrote:


 On 5/26/2013 7:48 AM, H. S. Teoh wrote:

 Ah, if only this code were written in D... :-P


 
 One possibility is to write the code in D, debug it, then recode the
 result in C to satisfy your customer.
 
 (Don't dismiss this out of hand - I've seen this sort of thing done
 before. Back when I was programming hand-held LED games for Mattel
 (remember those?) 
 


You worked on those? That's really cool, my friends and I used to love
those things (Or, actually, come to think of it, at that point they
were all LCD, not LED - roughly late 80's IIRC). Most of the ones I had
were "Tiger" brand though - was that part of Mattel or a competitor?
May 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/26/2013 12:56 PM, Nick Sabalausky wrote:

 On Sun, 26 May 2013 11:51:24 -0700
 Walter Bright <newshound2 digitalmars.com> wrote:


 On 5/26/2013 7:48 AM, H. S. Teoh wrote:

 Ah, if only this code were written in D... :-P


 One possibility is to write the code in D, debug it, then recode the
 result in C to satisfy your customer.

 (Don't dismiss this out of hand - I've seen this sort of thing done
 before. Back when I was programming hand-held LED games for Mattel
 (remember those?)


 You worked on those? That's really cool, my friends and I used to love
 those things (Or, actually, come to think of it, at that point they
 were all LCD, not LED - roughly late 80's IIRC). Most of the ones I had
 were "Tiger" brand though - was that part of Mattel or a competitor?


Yeah, I did the 'Soccer' one. For minimum wage! It was in 1978 or so. The 
display was a grid of red LEDs.
May 26 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 26 May 2013 13:04:50 -0700
Walter Bright <newshound2 digitalmars.com> wrote:


 On 5/26/2013 12:56 PM, Nick Sabalausky wrote:

 On Sun, 26 May 2013 11:51:24 -0700
 Walter Bright <newshound2 digitalmars.com> wrote:

 (Don't dismiss this out of hand - I've seen this sort of thing done
 before. Back when I was programming hand-held LED games for Mattel
 (remember those?)


 You worked on those? That's really cool, my friends and I used to
 love those things (Or, actually, come to think of it, at that point
 they were all LCD, not LED - roughly late 80's IIRC). Most of the
 ones I had were "Tiger" brand though - was that part of Mattel or a
 competitor?


 
 Yeah, I did the 'Soccer' one. For minimum wage! It was in 1978 or so.
 The display was a grid of red LEDs.


Cool. I did a couple of indie/budget games back in late high school,
early college (roughly 1998-2002) for royalties that probably ended up
working out to much less than minimum wage. But it still beat the hell
out of McDonald's! ;)
May 26 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/26/2013 1:21 PM, Nick Sabalausky wrote:

 Cool. I did a couple of indie/budget games back in late high school,
 early college (roughly 1998-2002) for royalties that probably ended up
 working out to much less than minimum wage. But it still beat the hell
 out of McDonald's! ;)


That's true. I learned a hell of a lot - best min wage job I ever had! I did a 
whole bunch of embedded systems then, and they were real projects for real 
customers, not demonstration projects.

The company I was working for, Aph, could have been Microsoft. But they
snatched 
defeat from the jaws of victory, and disappeared. Management simply had no idea 
what they had. (Of course, I had no idea at the time, either.)
May 26 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/26/2013 01:04 PM, Walter Bright wrote:


 Yeah, I did the 'Soccer' one.


   http://www.handheldmuseum.com/Mattel/Soccer.htm

That's before my time. :) I have played with ones similar to this though:

   http://www.handheldmuseum.com/Nintendo/Octopus.htm

Ali
May 26 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 26, 2013 at 05:20:59PM -0700, Ali Çehreli wrote:

 On 05/26/2013 01:04 PM, Walter Bright wrote:
 

Yeah, I did the 'Soccer' one.


 
   http://www.handheldmuseum.com/Mattel/Soccer.htm
 
 That's before my time. :) I have played with ones similar to this though:
 
   http://www.handheldmuseum.com/Nintendo/Octopus.htm


[...]

Whoa. This one brings back the memories! Was this the one where you had
to evade the tentacles and get to the sunken ship and back? I must've
been a primary schoolboy when I played this game (never owned it though
-- I used to visit my grand-uncle's electronics store and played it
there).


T

-- 
When solving a problem, take care that you do not become part of the problem.
May 26 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 27 May 2013 at 01:29:12 UTC, H. S. Teoh wrote:

 On Sun, May 26, 2013 at 05:20:59PM -0700, Ali Çehreli wrote:

 On 05/26/2013 01:04 PM, Walter Bright wrote:
 

Yeah, I did the 'Soccer' one.


 
   http://www.handheldmuseum.com/Mattel/Soccer.htm
 
 That's before my time. :) I have played with ones similar to 
 this though:
 
   http://www.handheldmuseum.com/Nintendo/Octopus.htm


 [...]

 Whoa. This one brings back the memories! Was this the one where 
 you had
 to evade the tentacles and get to the sunken ship and back? I 
 must've
 been a primary schoolboy when I played this game (never owned 
 it though
 -- I used to visit my grand-uncle's electronics store and 
 played it
 there).


 T


Oh man! My first handheld,

http://www.gameandwatch.com/screen/widescreen/manhole/index.html
May 26 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 27 May 2013 08:22:02 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:


 On Monday, 27 May 2013 at 01:29:12 UTC, H. S. Teoh wrote:

 On Sun, May 26, 2013 at 05:20:59PM -0700, Ali =C7ehreli wrote:

 On 05/26/2013 01:04 PM, Walter Bright wrote:
=20

Yeah, I did the 'Soccer' one.


=20
   http://www.handheldmuseum.com/Mattel/Soccer.htm
=20
 That's before my time. :) I have played with ones similar to=20
 this though:
=20
   http://www.handheldmuseum.com/Nintendo/Octopus.htm


 [...]

 Whoa. This one brings back the memories! Was this the one where=20
 you had
 to evade the tentacles and get to the sunken ship and back? I=20
 must've
 been a primary schoolboy when I played this game (never owned=20
 it though
 -- I used to visit my grand-uncle's electronics store and=20
 played it
 there).


 T


=20
 Oh man! My first handheld,
=20
 http://www.gameandwatch.com/screen/widescreen/manhole/index.html
=20


These were my first:

http://www.handheldmuseum.com/Tiger/Pinball.htm
http://www.handheldmuseum.com/Tiger/ElectronicFootball.htm
http://www.handheldmuseum.com/Tiger/DoubleDragon.htm
http://www.handheldmuseum.com/Tiger/NinjaGaiden.htm

(I like this thread, it makes me feel comparatively young ;) )

I played the heck out of those pinball and football ones. Strange
though, I had totally forgotten about those two until browsing that site
just now.

I also had the Castlevania II, MegaMan 2, and some racing one from a
different company, not sure who. No idea what happened to any of them.
(The watch one I remember I lost a loooong time ago.)

Many years later I participated in a very fun little "Make an
LCD-handheld style game" homebrew competition with a GBA entry (got
third place): http://pdroms.de/files/gameboyadvance/my-robot-v1-0
May 27 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 27.05.2013 09:13, schrieb Nick Sabalausky:

 On Mon, 27 May 2013 08:22:02 +0200
 "Paulo Pinto" <pjmlp progtools.org> wrote:


 On Monday, 27 May 2013 at 01:29:12 UTC, H. S. Teoh wrote:

 On Sun, May 26, 2013 at 05:20:59PM -0700, Ali Çehreli wrote:

 On 05/26/2013 01:04 PM, Walter Bright wrote:


 Yeah, I did the 'Soccer' one.


    http://www.handheldmuseum.com/Mattel/Soccer.htm

 That's before my time. :) I have played with ones similar to
 this though:

    http://www.handheldmuseum.com/Nintendo/Octopus.htm


 [...]

 Whoa. This one brings back the memories! Was this the one where
 you had
 to evade the tentacles and get to the sunken ship and back? I
 must've
 been a primary schoolboy when I played this game (never owned
 it though
 -- I used to visit my grand-uncle's electronics store and
 played it
 there).


 T


 Oh man! My first handheld,

 http://www.gameandwatch.com/screen/widescreen/manhole/index.html


 These were my first:

 http://www.handheldmuseum.com/Tiger/Pinball.htm
 http://www.handheldmuseum.com/Tiger/ElectronicFootball.htm
 http://www.handheldmuseum.com/Tiger/DoubleDragon.htm
 http://www.handheldmuseum.com/Tiger/NinjaGaiden.htm

 (I like this thread, it makes me feel comparatively young ;) )

 I played the heck out of those pinball and football ones. Strange
 though, I had totally forgotten about those two until browsing that site
 just now.

 I also had the Castlevania II, MegaMan 2, and some racing one from a
 different company, not sure who. No idea what happened to any of them.
 (The watch one I remember I lost a loooong time ago.)

 Many years later I participated in a very fun little "Make an
 LCD-handheld style game" homebrew competition with a GBA entry (got
 third place): http://pdroms.de/files/gameboyadvance/my-robot-v1-0


Very interesting, thanks for sharing.
May 27 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 26 May 2013 13:18:32 +0200
Paulo Pinto <pjmlp progtools.org> wrote:

 
 Did you had the pleasure to write portable C or C++ code across
 multiple operating systems and vendors in the mid 90's?
 


Luckily, no. For me it was just Win9x and DOS (using that awesome 32-bit
extender DOOM and every other game of the time used, forget the name.
DOS4GW?). And it was more mid-to-late 90's for me. (And then a little
bit of PalmOS around 2000 or so.)


 Welcome to #ifdef spaghetti code and reluctance of using certain 
 features due to inconsistent support.
May 26 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 26 May 2013 at 19:49:44 UTC, Nick Sabalausky wrote:

 On Sun, 26 May 2013 13:18:32 +0200
 Paulo Pinto <pjmlp progtools.org> wrote:

 
 Did you had the pleasure to write portable C or C++ code across
 multiple operating systems and vendors in the mid 90's?
 


 Luckily, no. For me it was just Win9x and DOS (using that 
 awesome 32-bit
 extender DOOM and every other game of the time used, forget the 
 name.
 DOS4GW?). And it was more mid-to-late 90's for me. (And then a 
 little
 bit of PalmOS around 2000 or so.)


 Welcome to #ifdef spaghetti code and reluctance of using 
 certain features due to inconsistent support.




Back in 2000-2001 I was responsible for making a C codebase work 
across HP-UX, Solaris, Aix, Linux and Windows NT/2000, while 
using the OS vendors C compilers.

Lots of fun with C standard compliance, this is where my #ifdef 
spaghetti code experience comes from. And the last time I really 
used C at work, before I moved definitely into C++/JVM/.NET land.

When I left the company in 2003, they were starting the 

with C++/CLI bindings to the "legacy" stuff.

--
Paulo
May 26 2013
prev sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 26/05/13 15:44, H. S. Teoh wrote:

 On Sun, May 26, 2013 at 01:27:55PM +1000, Peter Williams wrote:

 On 26/05/13 11:59, Nick Sabalausky wrote:


 [...]

 Forget waiting for a huge improvement, I'd have been happy to
 ditch C++ even for a small improvement. C++ is such a pain IMO that
 using it has about as much inertia as ice skates on concrete.


 I found shifting from C++ to C an improvement.  (Yes, I learnt C++
 before I learnt C.)  I should mention that this was back in the mid
 90s and C++ may have improved since then :-).


 [...]

 You're not the only one who felt that way. At my day job we also
 "upgraded" from C++ back to C. I've often ranted about our horrific
 experience with a hugely over-engineered C++ system that can literally
 do *anything*... except that nobody understood how to use the thing. It
 had dtors with side-effects that did useful work, for instance, and
 there were so many levels of abstraction it was bordering on insanity.
 Once I had to make a function call to said horrible code... it involved
 going through 6 layers of abstraction, two of which were fwrite()ing
 function arguments to a temporary file, then fork() and exec()ing an
 auxilliary utility that fread() the arguments back, and *then*
 dispatched them across an IPC link...


Makes debugging fun doesn't it? :-)


 We're now back in C-land, and boy the code is much cleaner, and
 *faster*, even though it's a lot harder to read and more tedious to
 maintain.

 Like I've said many times before, the only way I found coding in C++
 tolerable was to use it as "C with classes". Trying to do real OO in C++
 is an exercise in masochism. Even Java with its baroque verbosity and


Amen to that.  One reason I've avoided Java is that I found the signal 
to noise ratio in the source code VERY low and this made reading such 
code to find the bit that actually did something difficult.  I am (or 
was), however, a fan of the Java Virtual Machine (JVM) because it offers 
"run anywhere" functionality.


 prolific boilerplates beats C++ hands-down in this respect. And don't
 even mention templates, which are already nasty enough to work with in
 simple generic types; they are utter monstrosities when you start
 getting into CTFE and compile-time codegen. D templates, CTFE, and
 mixins, by contrast, are actually *pleasant* to work with.


I agree.  Although I'm still learning D I'm finding it a pleasure with a 
very high signal to noise ratio in source code.  Plus most features just 
work like one wishes the would.

Peter
May 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 25 May 2013 at 23:21:59 UTC, Klaim - Joël Lamotte 
wrote:

 I think this have not been posted yet around here but might be 
 interesting
 to the D community as it is actually criticizing several 
 languages
 including D but with an interesting aproach:

 http://sebastiansylvan.wordpress.com/2013/05/25/language-design-deal-breakers/

 Joel Lamotte


I agree on every single point.
May 26 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 26, 2013 at 01:13:30PM +0200, Paulo Pinto wrote:
[...]

 Now it is too late for it, but at the time C could have stayed as
 powerful as it is while offering:
 
 - proper modules, or at least namespaces
 
 - no automatic conversions between arrays and pointers. how hard it
 is to write &a[0]?


I think this was a historical accident. The original C, being an
abstraction of assembly, simply inherited the convention of using a
memory address to refer to some data, be it singular (pointer) or plural
(array). Of course, in retrospect, this conflation was a bad idea, but
it's not surprising why this choice was made.



 - arguments by reference, no need to check for null for every parameter


Again, this was a historical accident. In assembly, there is no
distinction between a pointer and a reference, so it's not surprising
why the inventors of C didn't make that distinction also. In retrospect,
of course, this would've been a huge improvement, but as they say,
hindsight is always 20-20.



 - strong typed enumerations


I've always been on the fence about this one. I wonder how things would
have turned out if Kernighan and Ritchie had made a distinction between
proper enumerations (nothing outside of the set is allowed) and what's
essentially an int with named values (values outside the set of names
are allowed). I find that a lot of C code actually want the latter, not
the former, esp. with bitfields.



 - memory allocation without requiring the developer to use sizeof
 everywhere


And typecasts everywhere. I mean, seriously, it's so incredibly annoying
to keep writing:

	myLongNamedType *t = (myLongNamedType *)malloc(sizeof(myLongNamedType) * n);
	if (!t) { ... }
	...

over and over and over. Talk about verbosity. (And this isn't even
Java!)

In retrospect, though, I can understand why it was done this way (malloc
was just another library function), but again, hindsight is 20-20. Back
then there was a lot of pressure to minimalize the language; nowadays we
know better, and realize that certain things, like memory allocation,
really are much better handled within the language itself.



 - strings similar to what D has


Yeah, ASCIIZ was both a blessing and a curse. A blessing in that you
don't have to keep passing a length around; a curse in that sometimes
passing a length around is the right thing to do.



 - proper arrays, after all the compilers for other languages always
 offered control over when bound checking code was generated


Well, in those days, premature optimization was king, and I can see why
C went the way it did. Saving every last byte was always a top concern,
even if today we scoff at it (and rightly so!). Time proved, though,
that ultimately we *had* to keep the length around for various reasons
anyway, so in retrospect they should've been included in the first
place.



 In the end, same syntax, just some semantic improvements on the type
 system.
 
 But now it is too late, we only have modern C++ with its warts, or

 replacement.
 
 However, given that C and UNIX are one and only, it will outlive us all.


[...]

I don't know, if we get our act together in polishing up D, we may yet
live to see the rightful demise of C (or more likely, its fading into
the obscure dusts of time). I'm hopeful, anyway. :)


On Sun, May 26, 2013 at 05:22:18AM -0400, Nick Sabalausky wrote:

 On Sun, 26 May 2013 13:27:55 +1000
 Peter Williams <pwil3058 bigpond.net.au> wrote:

 
 I should mention that this was back in the mid
 90s and C++ may have improved since then :-).
 


 
 I dunno. The more I learned about C++'s more advances features the
 more disillusioned I became with it. I was always happiest (or at
 least, least unhappy) with the "C with classes" form of C++.


Have to agree with that. Though when templates first came out, they were
a huge thing for me. It was only later that it became clear that the way
C++ handled them was ... well, it left a lot to be desired. :) When I
got acquianted with D's templates, I was totally blown away. It was like
a veil was lifted and I saw for the first time what a *real* template
system ought to look like.



 But then again, maybe that has nothing to do with "older C++ vs newer
 C++"?


"C with classes" *was* the older C++, whatever that meant. Since then
C++ has been trying to become purely OO (and failing horribly, IMO --
Java takes the cake in that area, no matter how much I may dislike that
fact), and tried to clean up the horrible mess it inherited from C (but
not very successfully). C++11 (finally!) introduced lambdas and type
inference, and a bunch of other stuff, but ... meh. A lot of it feels
like "too little, too late".


T

-- 
Indifference will certainly be the downfall of mankind, but who cares?
-- Miquel van Smoorenburg
May 26 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 26.05.2013 17:18, schrieb H. S. Teoh:

 On Sun, May 26, 2013 at 01:13:30PM +0200, Paulo Pinto wrote:
 [...]

 Now it is too late for it, but at the time C could have stayed as
 powerful as it is while offering:

 - proper modules, or at least namespaces

 - no automatic conversions between arrays and pointers. how hard it
 is to write &a[0]?


 I think this was a historical accident. The original C, being an
 abstraction of assembly, simply inherited the convention of using a
 memory address to refer to some data, be it singular (pointer) or plural
 (array). Of course, in retrospect, this conflation was a bad idea, but
 it's not surprising why this choice was made.



 - arguments by reference, no need to check for null for every parameter


 Again, this was a historical accident. In assembly, there is no
 distinction between a pointer and a reference, so it's not surprising
 why the inventors of C didn't make that distinction also. In retrospect,
 of course, this would've been a huge improvement, but as they say,
 hindsight is always 20-20.



 - strong typed enumerations


 I've always been on the fence about this one. I wonder how things would
 have turned out if Kernighan and Ritchie had made a distinction between
 proper enumerations (nothing outside of the set is allowed) and what's
 essentially an int with named values (values outside the set of names
 are allowed). I find that a lot of C code actually want the latter, not
 the former, esp. with bitfields.



 - memory allocation without requiring the developer to use sizeof
 everywhere


 And typecasts everywhere. I mean, seriously, it's so incredibly annoying
 to keep writing:

 	myLongNamedType *t = (myLongNamedType *)malloc(sizeof(myLongNamedType) * n);
 	if (!t) { ... }
 	...

 over and over and over. Talk about verbosity. (And this isn't even
 Java!)

 In retrospect, though, I can understand why it was done this way (malloc
 was just another library function), but again, hindsight is 20-20. Back
 then there was a lot of pressure to minimalize the language; nowadays we
 know better, and realize that certain things, like memory allocation,
 really are much better handled within the language itself.



 - strings similar to what D has


 Yeah, ASCIIZ was both a blessing and a curse. A blessing in that you
 don't have to keep passing a length around; a curse in that sometimes
 passing a length around is the right thing to do.



 - proper arrays, after all the compilers for other languages always
 offered control over when bound checking code was generated


 Well, in those days, premature optimization was king, and I can see why
 C went the way it did. Saving every last byte was always a top concern,
 even if today we scoff at it (and rightly so!). Time proved, though,
 that ultimately we *had* to keep the length around for various reasons
 anyway, so in retrospect they should've been included in the first
 place.



 In the end, same syntax, just some semantic improvements on the type
 system.

 But now it is too late, we only have modern C++ with its warts, or

 replacement.

 However, given that C and UNIX are one and only, it will outlive us all.


 [...]

 I don't know, if we get our act together in polishing up D, we may yet
 live to see the rightful demise of C (or more likely, its fading into
 the obscure dusts of time). I'm hopeful, anyway. :)


I do understand why many of C decisions where made, specially 
interesting is to read Ritchie's history on how everything came out to be.

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

I started using computers at the age of 10 back in 1986, so there
are a few things that I missed about those early languages.

However given my special interest in language design and the endless set 
of information my university used to offer, I devoured all the 
publications I could put my hands on. According to many of those papers 
some of the languages available on those days for systems programming 
could have provided for a safer C, assuming their designers were aware 
of them.

Then UNIX's popularity made everyone have the same tools on their home 
systems and we got C instead of Modula-2 or similar languages.

I am not religious and will use it if it makes sense to do so, but since 
2001 I don't miss it.

--
Paulo
May 26 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 26 May 2013 08:18:11 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 Back then there was a lot of pressure to minimalize the
 language; nowadays we know better...


No we don't. Some of us do, like those of us here in D-land. But from
what I've seen there's still a *lot* of belief in keeping languages
minimal.



 
 On Sun, May 26, 2013 at 05:22:18AM -0400, Nick Sabalausky wrote:

 
 I dunno. The more I learned about C++'s more advances features the
 more disillusioned I became with it. I was always happiest (or at
 least, least unhappy) with the "C with classes" form of C++.


 
 Have to agree with that. Though when templates first came out, they
 were a huge thing for me. It was only later that it became clear that
 the way C++ handled them was ... well, it left a lot to be
 desired. :) When I got acquianted with D's templates, I was totally
 blown away. It was like a veil was lifted and I saw for the first
 time what a *real* template system ought to look like.
 


I always tended to avoid doing much of anything with C++ templates
simply because they were still new at the time and the implementations
were considered to still be somewhat buggy.

Around the same time, I was noticing that using any of the newer,
fancier, "better" features of C++ had a tendency to leave you needing
to *also* start using all of the other fancier features, too, many of
which were either awkward (being C++ and all) or known-buggy (the
templates at the time). So that was a big part of what made me start
loosing interest in C++.


 C++11 (finally!) introduced lambdas
 and type inference, and a bunch of other stuff, but ... meh. A lot of
 it feels like "too little, too late".
 


Yea. I generally feel that, regardless of whether or not those involved
are consciously thinking it, C++ is basically a rusty run-down old
engine on two working cylinders that's...not trying to catch up with D,
but just trying it's best not to fall too far behind, too quickly.
May 26 2013
prev sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Sat, 25 May 2013 23:50:28 +0100, Klaim - Jo=C3=ABl Lamotte  =

<mjklaim gmail.com> wrote:


 I think this have not been posted yet around here but might be  =



 interesting
 to the D community as it is actually criticizing several languages
 including D but with an interesting aproach:

 http://sebastiansylvan.wordpress.com/2013/05/25/language-design-deal-b=


reakers/



"Null pointer exceptions have no business in modern languages. Getting r=
id  =

of them /costs no performance/, and statically eliminates the one big  =

remaining cause of runtime crashes that we still see in otherwise =E2=80=
=9Cmodern=E2=80=9D  =

languages."

/emphasis/ mine.  Is it actually true that you can "remove" null pointer=
  =

exceptions at no runtime cost?

It's possible if you remove pointers from the language.
It's possible if you statically require that any pointer/reference is  =

initialised at declaration.

But, is it otherwise possible?  Because both of these options are too  =

restrictive for a systems programming language.



can/will improve, eventually (bigger fish to fry).


r  =

fish to fry)

R

-- =

Using Opera's revolutionary email client: http://www.opera.com/mail/
May 28 2013
parent Ziad Hatahet <hatahet gmail.com> writes:
On Tue, May 28, 2013 at 7:37 AM, Regan Heath <regan netmail.co.nz> wrote:


 On Sat, 25 May 2013 23:50:28 +0100, Klaim - Jo=EBl Lamotte <
 mjklaim gmail.com> wrote:
 /emphasis/ mine.  Is it actually true that you can "remove" null pointer
 exceptions at no runtime cost?

 It's possible if you remove pointers from the language.
 It's possible if you statically require that any pointer/reference is
 initialised at declaration.

 But, is it otherwise possible?  Because both of these options are too
 restrictive for a systems programming language.


The Rust programming language managed to do that, and it is a systems
language (rust-lang.org).
May 28 2013