Next topic

[serprex]

http://coq.inria.fr/stdlib
Click a few links, you'll see some Coq code. This isn't the language suited for implementing Enigma

[RetroX]

I haven't read all of this, but what the hell happened in the last few hours.

C/C++ is a better language.  If you want to make loads of standard libraries in C++ for GC, pointer allocation, etc., that's fine with me.  In fact, I'd love that.

But forcing people to use them in the language is a completely terrible and bad thing to do.

You can't use the argument "IT'S JUST BETTER WITH JAVA" because it's not.  Yes, some Java APIs are better than what C++ has.  It does not mean that Java is a better language.

If the APIs aren't used by everyone, that means that they're obviously not good enough.  How many people use WinAPI?  How many Unix APIs have XLib as a base?

[luiscubal]

@seprex
Coq looks math. It could be considered at most functional programming, while C++(and Java too, by the way) is imperative.
GML is imperative too, making its implementation(or, should I say, translation) easier in C++ than in Coq.
Rusky already said that a modification to the C compiler would possibly work.

@RetroX
Here was I thinking that the flamewar was over. My mistake, sorry.

C/C++ is not a better language. It is different. Which is why you have so much trouble accepting Java and C#.
Pointer allocation is called malloc, calloc or new. It already exists in C++ and is widely used.
There is also GC for C++(see Boehm's, for example). However, they are imperfect. Far worse than GCs for GC-designed languages like Java.
Sure, C++ can have lots of things, but with each layer of abstraction you add, the syntax gets uglier and the language more complex. Java does the opposite. It adds those features and *still* has a simpler syntax. Java assumes everybody wants GC and turns out they were right for a HUGE percentage of all cases.

Now, to put this in a way you understand:
Java is a better language. If you want to make loads of standard libraries in Java for non-GC memory, pointer management, etc., that's fine with me. In fact, I'd love that.
But forcing people to use them(pointers, non-GC memory) in the language is a completely terrible and bad thing to do.

You can't use the argument "IT'S JUST BETTER WITH C++" because it's not. Yes, some C++ APIs are better than what Java has. It does not mean that C++ is a better language.

If the APIs are duplicated every day with no interoperability, that means they're obviously not standard enough.

---
Now that I put this out.
The above example is just to prove RetroX that his arguments can be used against him.
I don't consider Java to be absolutely better than C++ the way RetroX seems to think C++ is absolutely better than Java.
I certainly wouldn't care about a non-GC memory/pointer manipulation Java library(JNI-based, I guess).
C++ APIs are available in quantity, but that means fragmentation. Java includes lots of things in the standard library in a (partially successful) attempt to avoid that problem.
For the record, I don't consider Java to be the best language ever. I consider C# to be the best language, although I dislike GUI C# library inconsistent because it's the same problem C++ has. So the thing I hate most in C# happens to be a "feature" of C++? Neat, huh?

EDIT:

If the APIs aren't used by everyone, that means that they're obviously not good enough.  How many people use WinAPI?  How many Unix APIs have XLib as a base?

I actually missed that flaw. C++ APIs aren't used by everyone. The "not good enough" is obviously a C++ problem, not a Java problem(since everybody uses java.lang). So you just attacked your own language.
Exactly what are you trying to prove with the WinAPI/Xlib argument?

[freezway]

@josh: ur image link is broken

[Rusky]

Coq is not the only dependently typed language or way to implement dependent typing. As I said, you could add dependent typing to C.

@RetroX: No, C/++ is not a better language. GC and the safer memory design in Java/C# would require language-level changes before working in C/++. Java/C# doesn't require you to use the standard libraries either, any more than you're required to use your OS's API. Personally, I think Java is a worse language overall compared to C/++. What I'm saying is that it has several aspects where it is better, and some of those are impossible in C/++.

[Micah]

@serprex: Coq is not really what Rusky is talking about. It has dependent typing, but it's more of a theorem prover than a programming language. You could easily put dependent typing in a normal imperative programming language.

@RetroX, luiscubal: Java and C# are loads better than C++ for anything that's not low-level, but they're not nearly high-level enough. Basically, I would never choose them unless there were some library (e.g. XNA) on the frameworks around which they're built that wasn't anywhere else. Given the choice between them and C++, I would choose them every time, unless I needed to do something which actually needed pointers and manual memory management, in which case most of the abstractions with which C++ provides you would be stupid to use.

[The 11th plague of Egypt]

There is an off-topic section for this kind of discussions.

I wonder if these people code as much as they debate.

[kkg]

VISUAL BASIC IS THE BEST LANGUAGE LOLOLOLOLLOL


...

[The 11th plague of Egypt]

A quick question. It just came to my hear that you can deallocate a whole array in GM using the var trick

var A;
A[100]=0

Will it deallocate the whole array in Enigma too?

[Josh @ Dreamland]

A[100]=0 isn't anything special.

In GM, a map is used for array indexes, as far as I can discern.
A[100] creates a single new node in the map, and does some rearranging to improve lookup time later.

In ENIGMA, A[100] = 0 will in fact /allocate/ an array of that size for you to use, and will set the 100th element to zero.

I was considering adding a var::drop() or array_free(var& x) to take care of that in ENIGMA.
As far as I know, you can't deallocate an array in GM, except temporaries. Which are automatically freed at the end of the code.

[MrJackSparrow2]

Any news from the Devs? Josh, Ism?

[Josh @ Dreamland]

Quite a bit. ENIGMA finally stops segfaulting if it fails to load, as Ism just stops calling it if it returns nonzero. LGM will only show ENIGMA if it succeeds.
Also, it now works from platform to platform, right off the bat, provided only that it can find a version of the GCC. If it can't, Ism will ask for it.
I'm not sure about including JNA with the repository; I've no idea on its license (though I can't imagine it would forbid doing so), and Ism didn't include it...

If you check out the SVN and run a game with ENIGMA, right now, it will write all the files needed for compile, but it won't call GCC as I'm swapping out R3's system for Make. Furthermore, I'm swapping out R3's variable initializer for a less dated equivalent; this one will more accurately detect scoping now that we're mostly C++ compliant. The SVN repo will make you declare your variables until I keep track of used, undeclared ones as well as the declared ones. (This will be fixed first, probably).

Ism doesn't yet keep track of whitespace. She'll be working on that. LGM's code editor sucks. I'll be taking an attempt at coding a better one today, I believe.

[IsmAvatar]

JNA is LGPL.

Also, what's so wrong with our code editor anyways?

[The 11th plague of Egypt]

You can write a code editor in a day?

[IsmAvatar]

Yes.

{
JTextArea a = new JTextArea();
add(a);
}