so, I just heard someone say c/c++ is becoming a "niche" language like cobol...

[2EwbqMoL]

Actually I've heard a lot of comments like that recently -- all one needs to do is do a google search to see what I mean...

a lot of people these days are arguing that c/c++ is becoming archaic -- although usually the languages they're arguing for aren't as versatile or powerful.

I've heard C# argued as better, ruby, python, and even Delphi... but with the exception of Delphi, its usually interpreted languages (or virtual machine i.e. java) that tend to get reccomended.

dont these people (some serious coders) see the disadvantages in performance that this poses? sure I like c# a lot, and if I was going to make a windows only desktop application, I might use it. but for applications that need performance -- video games, multimedia apps, those kind of things, you really end up NEEDING the high performance of C/C++, and the multitude of libraries available (SDL, OpenGL, Ogre, the list goes on...) for it.

Back when I started screwing around with QBasic -- everything seemed to be about lower level programming, and getting native executables. I remember some of the awesome coders from the emulation scene (some were REALLY AMAZING programmers) would use ASM a lot -- sometimes for odd processor archetectures (usually when coding for dreamcast, PS1, xbox, etc), to get speed... people cared more about that stuff than just cranking out a program quickly.

dont get me wrong, Im not saying that C++ is the end all, hell, you can replace it with pascal and Id still argue the same -- people just dont seem to care about the same stuff they used to when it comes to programming languages...

Idk but to me, theres something exciting about having a native binary for a platform... Im like, yeah I made that. its not something you can open up and read -- its me talking directly to a machine, and it understanding me.

I've actually started screwing around in C# myself, and I like it -- but in no way are any of the .NET (or mono) or various scripting languages above C/C++... I mean seriously, especially in C#'s case its basically a rebranded visual basic with different (Id say nicer more elegant) organization -- syntax is pretty much the same too...

[Duthomhas]

On Losers
I think that people who tend to say things like that fall into two general groups:

1) those that don't know any better (weenies, reporters, etc), and

2) those with an agenda (language designers, academics, those with the arrogance to believe that their biases are so superior that they ought to be enforced on everyone else, etc)

NB. I did not say that all weenies, reporters, language designers, etc. are the kind of morons who make such statements...

A glance through the Wikipedia ought to get such people to pause, if not shut-up.
http://en.wikipedia.org/wiki/List_of_programming_languages_by_category
http://en.wikipedia.org/wiki/Programming_paradigm

If they are advocating an interpreted language over non-interpreted languages, then they really need a lesson in language design. Any language can be interpreted. And an interpreter must itself resolve to one or more compiled modules. Some of the 'worse' languages either existed or do still exist in interpreted forms --including Pascal and C!

(Compilers are actually a special form of interpreter: a transformer.)

People who really know what they are talking about are more interested in using the right tool for the job --if possible ('business concerns dominate technical preferences'[1])-- or just using the tool the Right Way.

[1] http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.5



On Opinions (mine)
Of course, none of this deprives anyone of their own opinions or preferences.

Personally, I like Pascal --but I think that the JPC and X3J9 committees have butchered the language much more than Borland has (though lately CodeGear seems to be trying to close the gap, alas). Even when a feature was otherwise identical in scope and purpose to something BP had already had for years it was defined so as to be completely incompatible.

I was going to write myself an EP compiler, and as I began scrutinizing the grammar I was horrified by its massiveness, loopholes, and near-complete disregard for Wirth's original emphasis on efficiency.

That said, there are some things that I would dearly like to see in Delphi: PXSC-style operator overloading; schemata, extended to work with types (schemata are templates in Pascal --though currently they are underpowered); and some of the EP module import/export powers (modules/units are basically namespaces in Pascal).

Hence, I am currently writing my own version of Pascal. :-) Hopefully I'll get a few more things right. (You can guess that I am not a fan of design-by-committee.)

I also like C++ quite a lot. I was never a huge fan of C over Pascal (despite the fact that they really are very different languages, in use they are actually quite compatible), but C++ is nearly as cool as dirt. (It still has its flaws, but outside of some failures in the STL's design they rarely bother me.)

Well, I guess it is time to put my soapbox away. :-P

[2EwbqMoL]

if/when you get done with your version of pascal, I'd like to take a look at it myself ;).

personally I agree with you that the organization of its designers has held it back...

have you considered opening up your version of Pascal as an open source project? Id be willing to bet you could garner some support and help for it, as well as get it done faster, and with more features then you originally inteded for..

I think itd be neat if you could pack up some graphics/sound libraries (SDL, OpenGL) into it...

but that would be making it my language not yours :P

but seriously, open source would be a good idea I think -- itd definitely keep it on the bleeding edge...

[Duthomhas]

Wow, already a groupie! :-P

Seriously though, I'd love some feedback. I just started though, so I'll wait until I get a working compiler and a specific standards document before I go to to SourceForge.

It will be compatible with ISO 7185, but not with Delphi, ISO 10206, or OOE. [edit]Although compatability units are a definite thought for the future.[/edit]

I plan to have some cool stuff though.
- most of EP's import and export powers (sans the circular crap)
- schemata extended to parameterize on types
- operator definition and overloading, a la PXSC (though I'm still not too sure on that priority keyword, but ATM I don't know how else to express the start of an operator declaration section, as the word operator is taken to declare a routine)
- record, class, and interface (but not EP's stupid, redundant, anti-pascalian view). I'm still not sure what to do with the object keyword, but it might be dumped entirely in favor of class. I'm also still not sure I want to use the EP restricted keyword --it also seems redundant.
- threadvar and critical section blocks
- exception handling of both software and hardware (OS) signals (which are actually very consistent across hardware)
- improved try block structure
- interrupt routines for low-level programming
- assembler routines and asm blocks. More notes on this follow.
- both simple and smart pointer types. More notes on this follow.
- currency, complex, and bignum types (that is, as built-in types) var c: complex = 3r+2i;
- dynamic array types (homogeneous data)
- dynamic list types (heterogeneous data)
- default parameters, variable argument lists, and maybe even named- and implicit- argument passing
- all structured types have automatic reference counting (including widestrings and objects)
- sets of any named-type (homogeneous data), in addition to the optimized ordinal-type sets
- case statements that work on strings
- propertys that are usable like any true variable (brought to you by...)
- enhanced heap management. Again, see notes below about smart pointers
- foreach in and for in sequence loops (see below)
- I'm still considering adding a step value to for x := statements. That is one thing I really missed from BASIC.
- constant initializers for anything, including in sub-blocks
- variant parts in classes (easy! so why not?)
- numeric constants in any radix in 2..36, expressed in a number of ways (conventional-style, EP-style, and my own style: %1010 = 2#1010 = 1010b)
- cleaned-up syntax
- improved heap management (over 'new', 'dispose' and 'getmem', 'freemem')
- automatic type introspection (without the need for RTTI)
- some relaxations on type compatabilities?
- true unicode support. [added by edit]

Hmm. I think that's it for now.

Notes:
Assembly
I'm thinking of providing a custom assembly language (in addition to the machine's native asm) so that modules can be pre-compiled and usable on any os --that is, without having to distribute source code. This is different than DLLs, which are OS-dependant, and which are not able to be statically linked into the resulting EXE, and which do not provide packed interface data. (I don't want to mess around with native DLL formats. [edit] That is, beyond the ability to compile and use them normally. ;-) [/edit])

Pointers and Heap Management
All computer hardware gives you the power to handle memory in a very convenient way --but usually only the OS makes use of these abilities (and old systems like MS DOS don't even do that).

This means smart pointers, scope-based garbage collection, and the aforementioned power to treat properties as if they were actual variables. The overhead to do these kinds of things are acceptable (relatively small, even), but completely avoidable if desired.

As in Delphi, all objects are allocated on the heap. I include records, strings, bignums, etc. and add automatic reference counting (for garbage-collection).

Use of smart pointers automatically handles the reference counting, and they codify something that is only nebulously taught about Delphi: references. (Hence, in my Pascal a reference is a smart pointer.)

Again, all this stuff can be avoided -- you are not forced to use references with objects.

Example:

type
  stupid: ^integer;   // this is a standard pointer
  smart:   integer^;  // this is a reference 

Foreach
For-statements are expanded to take a sequence. The two look identical but the semantics are different:

var
  x, y: integer;
begin
for x, y in [1, 2, 3], [4, 5, 6] do
  write( '(', x, ',', y, ') ' );
foreach  x, y in [1, 2, 3], [4, 5, 6] do
  write( '(', x, ',', y, ') ' )
end

The for loop takes the sequences linearly --as if concatenating them-- and produces

(1,2) (3,4) (5,6)

The foreach loop takes the sequences in parallel --as if zipping them-- and produces

(1,4) (2,5) (3,6)

This is just a little Tclism I like.

Libraries
Only a very few routines will be defined by the language. Everything else will be a library. I have in mind SDL and a cross-platform windowed library, but that is to be fleshed-out after I get this compiling console stuff. :-)

Well, I'm hungry, so let me know what you think and give any suggestions for improvement,etc.

[Faldrax]

Foreach
Interesting - when i read this my first thought was that it should perform the action for each combination
IE

(1,4)(1,5)(1,6)(2,4),(2,5),(2,6)(3,4)(3,5)(3,6)

which would also be useful in some circumstances.

[Duthomhas]

Hmm, good point.

I can see this getting out of control. Perhaps I should just always take a single sequence linearly and require the user to order/concatenate/zip/combine/etc. things using functions.

for x, y in (1, 2, 3) + (4, 5, 6) do ...

for x, y in zip( (1, 2, 3), (4, 5, 6) ) do ...

for x, y in combinations( (1, 2, 3), (4, 5, 6) ) do ...

I'm also struggling a little with implicit array and list constructor syntaxes. I would like to do as above, and be able to automatically construct lists and arrays.

Currently my grammar has

list-constructor
: '(' (expression-list)? ')'

set-constructor
: '[' (set-element-list)? ']'

but how do I represent an array constructor? Sure, there are typed constants:

array-constant
: '(' typed-constant (',' typed-constant)* ')'

but a typed-constant can only appear as part of an initializer, not as an expression itself.

Maybe the difference between a list constructor and an array constructor should just be whether the elements are homogeneous or not?

[edit] I'm aware of Delphi's Open Array Constructors, which I find to be syntactically grating... [/edit]

Hmm...

[Zaita]

so, I just heard someone say c/c++ is becoming a "niche" language like cobol...

Is it true? In a nutshell, yes.

This is mostly because alot of educational institutes no longer teach it. They get given Microsoft tools for free, so it's a perceived better value.

It's also easier for them to have tutors to teach (badly) a language with garbage collection, and a nice industry constant IDE.

In saying that, COBOL developers are still required, and they make a fortune doing what they do. That's the beauty of a niche.

I've actually started screwing around in C# myself, and I like it

C# is a good language, the syntax is nice and the .NET platform is fairly well designed.

-- but in no way are any of the .NET (or mono) or various scripting languages above C/C++...

Why not? Your going to sound like a tech-weenie here by debating semantics of 1 language against another on technical merit.

.NET is a good platform and has fit it's purpose nicely. It's an ideal RAD platform from a business perspective for development.

I mean seriously, especially in C#'s case its basically a rebranded visual basic with different (Id say nicer more elegant) organization -- syntax is pretty much the same too...

I hope your not comparing C# to VB.NET. That'd be ridiculous.

However, if comparing it to VB6 then:
C# is more a modified version of Java than any resemblance to Visual Basic 6. The Syntax between any .NET languages is almost identical, but thats the point. They are all interpreted by the same runtime engine. Visual Basic .NET is vastly different to Visual Basic 6.