Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Josh @ Dreamland

2116
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 11:48:44 PM »
"You haven't provided any cases where a runtime check for array bounds is necessary."
Code: [Select]
int x[ftoi((scanf("%d",&a),a))];
for (int i=0; i<25; i++)
  x[i] = properties[i];

"But it does not give you the productivity of a high-level language."
Sure. That's up to a good library. And/or a good set of macros. Like serp's continue(2) hack. Or a separate parser, which often isn't even the most efficient answer itself, but seems to be the best option.

2117
Announcements / Re: Anaphase
« on: April 10, 2010, 11:11:05 PM »
Buh?

2118
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 11:09:12 PM »
"How? You said that there have to be runtime checks. I was saying how there do not have to be runtime checks. How is that beating around the bush?"
You've provided one more case to cling to the idea that a runtime check isn't necessary. You've in no way shown that they are rendered unnecessary.

"LOL INVALID IS JUST A WORD YOU USE TO SOUNDS SMART"
Note the italicized word "argument." A premise, as I said before, can not be invalid. It can be true or false. Describing a premise as invalid is done in a failed attempt to sound smart. ...Nice try, though.

"Valgrind is a hack because it's meant to work around the limits of C++. And Valgrind does not provide even close to what high-level languages provide. And you still haven't shown that it provides even just what dependent typing provides."
So it's a limit of a language only if every implementation of said language doesn't come with the feature. Hm.
Also, you've nothing to back that up, and I have no idea what proof you could want of what valgrind can do. Look it up. Find a project worth using it on.

"Care to explain what you mean by this remark? I'm not sure what you're getting at."
No. I chose to leave that open to interpretation.

2119
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 10:25:54 PM »
Quote
Because JavaScript was designed for Unity. Exactly.
Also, you can use C# or Boo with Unity if you don't like JavaScript's divide-by-zero handling.
Never stated the former. I stated merely that JavaScript was not designed in a manner that only supports web browsers.
The latter is irrelevant.

Quote
I never claimed that they're all better than C++.
Likewise, I assure you.

Quote
But it can check if you're checking that the length is greater than the indices you're using on it.
All these buts are just beating around the bush.

Now, in the rest of your post, you finally start building an argument. Which quickly runs invalid. This is how you show an argument is invalid.

i. We decided that Valgrind and dependent typing are the same in that "Valgrind is a hack to replace dependent typing; both let you do the debugging up front."
ii. What was not defined, to this point, is how Valgrind is a hack. I asserted "So, it's non-hackish because it's done automatically instead of by request" without resistance.
iii. You assert that dependent typing only informs of what needs checked.
iv. Valgrind only informs of what needs checked.

Seeing that premise ii implies an inequality which premise iv destroys, one of those must be false. Care to define a new grounds by which Valgrind is a hack?

"This has never been about low-level languages versus high-level languages. This has been about using the right tool for the job--using low-level languages for low-level tasks and high-level languages for high-level tasks."
My, what a perfect world it would be if you could just embed a low level language into a high, or even just mix--ffffffffffffffffffuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

2120
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 09:24:17 PM »
This design is probably mainly due to the environment in which JavaScript almost always runs: browsers.
See Unity. Marbs is presently writing Dominoes 3 in JavaScript.

One example of a language that makes it hard to find bugs related to division by zero does not mean that C++ is better for everything than high-level languages.
And vice-versa, mind you.

"Arrays can be resized. It would change the type. If you had dependent typing in an imperative programming language, you just wouldn't make a specific size part of the array variable's type. Values can have more specific types than the variables that contain them."
Yes, yes, yes. Now tell me what size type int x[ftoi((scanf("%d",&a),a))] has, and how many witty optimizations can be done around it. Rusky stated how such was handled (though then dropped out): runtime.

From there, it's down to personal preference. Valgrind and dependent typing we've decided to be the same, so. In the event of the unforseen, I prefer the program to die rather than to waste time every access making sure it lives.

2121
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 09:04:19 PM »
Quote
Infinity and NaN are pretty much errors for numbers in JS. They are in no way glitching.
So, you're denying that treating a number as Infinity and proceeding like nothing happened could ever produce a behavior not accounted for by the programmer. I see.

Quote
You were saying that you'd rather do things Valgrind's way. He was saying that dependent typing is a non-hackish way to do the same things that Valgrind does.
So, it's non-hackish because it's done automatically instead of by request? Pffft.

Quote
Obviously you haven't really learned how dependent typing works. The length of an array would be in its type. If there is ever the possibility that an array can be indexed out-of-bounds, i.e. it is indexed with a number whose range is not completely a subset of its range of indices, you will get an error.
Uh-huh. So I guess arrays can simply never be resized, especially to an arbitrary or user-defined size. Well, at least it's safe and efficient.

Quote
You completely misunderstood what Rusky said. Non-trivial programming is not something that would not produce segfaults. Non-trivial programming is programming non-trivial things, in which segfaults would probably happen much more often in low-level languages than they would when programming trivial things.
Meant trivial programming. Fixed.

2122
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 08:37:55 PM »
"Uh, what? Do you have any sources at all to back up this utter nonsense? Did you even think at all about this statement before posting it? That is completely false."
Quote
Josh @ Dreamland:
js: 1/0
js:
Infinity
So much for being "completely false," as you regard most of my statements that aren't to your liking.
Buffer overflows kill the program nine times out of ten. The rest are detected 100% of the time by any decent debugger.
Languages with better exception handling can catch such things; not all do. JavaScript's my favorite example of one that doesn't react in any way to division by zero; defining it as Infinity won't always cause the correct behavior.

"...Yes. Your argument was that you wanted to do "debugging up front" with Valgrind instead of using a good high-level language and type system, which, for some reason, you dubbed "letting the program do it constantly" (whatever the heck that means). Rusky was stating that that is completely invalid."
He seemed to be comparing Valgrind to dependent typing, not stating that anything was "invalid" (Which, I might add, a simple premise can't be; people just like to say "invalid" to sound smart). Consistent checking didn't refer to dependent typing; quit pretending that dependent typing can account for 100% of bounds error checking. It catches much; the rest is handled runtime.

"Please try writing more clearly. I have no idea what you mean by this."
Probably because that was a very serprex-ish statement. Trivial programming--the kind that would not produce segfaults--is what the really-high-level languages are apparently good for.

2123
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 07:39:51 PM »
"Valgrind is a hack to replace dependent typing; both let you do the debugging up front."
Does anything follow from that, or...
"Segfaults aren't the only error that comes from using lower level languages."
You chose not to name examples, or...
"Null pointer exceptions don't exist in actually-higher-level languages (i.e. excluding Java)."
Neither do divide by zero errors; they just cause glitching.
"Not having run into segfaults means you haven't done any non-trivial programming."
Like the kind one might use a high level language for to avoid such...

2124
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 06:28:59 PM »
"They happen once every 2 days on average."
I've had four segfaults in total in the past year. They each took between five and twenty minutes to fix.

2125
Announcements / Re: Anaphase
« on: April 10, 2010, 06:25:14 PM »
Quote
Have DirectX graphics been implemented yet, or is that purely there for preparation?  Also, in the future, would it be possiblw to write things for ENIGMA (not necessarily you, but maybe someone else could help with it after r4 is released) for WINDOW=WIN64, WINDOW=GTK, and WINDOW=WXWIDGETS?
Purely preparatory. Yes, all of those would be fine if they are structured the same way as the two currently implemented systems.

Quote
EDIT: If ENIGMA is a DLL, what is going to be used for the GNU/Linux version?  You can't link Java to a shared library, afaik.
Can, and did.

2126
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 05:14:13 PM »
*cough*
Valgrind

I'd rather invest any amount of time into debugging up front than let the program do it constantly.
...But that's just me.

2127
Announcements / Re: Anaphase
« on: April 10, 2010, 12:09:27 AM »
God, I hope so. If no one yet cares about interface, for which output redirection currently is STILL BROKEN, then I don't see why not. As long as the makefile gets written. I've asked Aragon to allow for parameters GRAPHICS=GL, WINDOW=WIN32, and WINDOW=XLIB. If he can add those... We'll be in good shape.

I'm going to add template tolerance and automation tomorrow. Ism can hopefully fix output redirection as soon as/before Aragon has makefile working. All else is looking good. Just fixed/seemingly finished implicit typing again. Have to make sure scope applies to it...

Presently it will flip shit if you say, for example,
if (true)
  int a = 0;
As the behavior of that is meaningless in C++ and undefined in ENIGMA. Will see what I can do about it. (It's technically as simple as finding non-'n' letter tokens and pushing the scope until ';', but...)

2128
Announcements / Re: Anaphase
« on: April 09, 2010, 10:43:31 PM »
Yes, that's what was decided...
Aragon is actually taking care of the makefiles now. Which makes him important. With a little luck, ENIGMA will simply pass a couple flags to the makefile and be done. Then only cross-compiler makefiles, such as that for the Wii, will be separate.

2129
Announcements / Re: Anaphase
« on: April 09, 2010, 07:30:31 PM »
"We" refers to the group of people who are here because they actually want to see ENIGMA succeed. That includes him; it's sensible that anyone who cared for the success of ENIGMA would want to make a good impression.

As for the C parser, that I'll grant; it took a lot longer than I'd hoped, as I decided as I went to add more features. Originally I wanted to just collect function and class names, but then I realized I could do so much more with a full description of what was included...

I can't really say the same for a simple code editor.

2130
Announcements / Re: Anaphase
« on: April 09, 2010, 05:35:33 PM »
"i agree with MJS. i want the meat!"
Working on it.

"would it be posisble to make a syntax highliter for like... say... gedit?"
GEdit does have one... open any header in it.

Also, a code editor wouldn't slow the release much.