26 May, 2010, Runter wrote in the 101st comment:
Votes: 0
David Haley said:
Quote
I think it's a misconception because in many higher level languages it exposes the low level API directly. For example, you can interlace C/C++ into your Ruby code pretty seamlessly to define methods on your classes that need to be fine tuned at a low level way.

Well, if the statement is that you have control because you can use C/C++ extensions to give you that control, I won't disagree with that. But that seems like saying that in the end of the day, you have the control because C++ gives it to you. :smile:

That said, you still don't get control over details like object deletion, memory block allocation, etc., short of (again) using extensions to do it. I think that this is the kind of stuff that is considered low-level.


I guess, but it depends on the high level language in question. In a way writing in Ruby is like writing in C with a DSL. It all corresponds to C. You can extend it, write your own C. But I'm not really talking about the "extension" process. There's inline builders that let you use C, C++, or any other language your system can build from as well. Those don't really count towards the "extension system."

I'm being pretty Ruby specific but I suspect there's facilities like this in other high level languages to give you the control you need to identify and reduce bottlenecks when necessary.

Edit:
Also, I'm being a little Ruby specific here, but there's a new implementation out just this month that implements Ruby out of the Ruby interpreter. I.e. the core is written in Ruby. This would give you some of the access you're talking about straight from the code.
27 May, 2010, David Haley wrote in the 102nd comment:
Votes: 0
I guess that I'm just trying to avoid the somewhat uninteresting definition where every language with a foreign function interface to C provides equal access to low-level facilities as C itself. That is clearly missing something important, otherwise you're essentially saying that there isn't really any reason to use C directly.

Incidentally I would definitely not say that Ruby "corresponds" to C unless you are saying that it gets compiled to C. The interpreter bring in C doesn't make the interpreted language correspond to C except in the trivialized sense that it all can be reduced to assembler in the end.
27 May, 2010, Runter wrote in the 103rd comment:
Votes: 0
Quote
Incidentally I would definitely not say that Ruby "corresponds" to C unless you are saying that it gets compiled to C. The interpreter bring in C doesn't make the interpreted language correspond to C except in the trivialized sense that it all can be reduced to assembler in the end.


*shrug* You can go see what any function does in C in the standard library. Imo, that corresponds to C code. Sounds like you're picking trivial nits here.
27 May, 2010, David Haley wrote in the 104th comment:
Votes: 0
I'm just trying to say that there is something exceedingly different between C and an interpreted language implemented in C. I'm a little shocked at your position, actually. You're basically saying that *any* language implemented in C is basically C. Also, that std lib functions happen to be in C says absolutely nothing about the whole Ruby program somehow being C.
27 May, 2010, Runter wrote in the 105th comment:
Votes: 0
David Haley said:
I'm just trying to say that there is something exceedingly different between C and an interpreted language implemented in C. I'm a little shocked at your position, actually. You're basically saying that *any* language implemented in C is basically C. Also, that std lib functions happen to be in C says absolutely nothing about the whole Ruby program somehow being C.


I think you're extrapolating something I'm not saying. And frankly, I'm going to steal one of your common lines. I'd appreciate it if you didn't take the most stupid meaning possible and assume that's my position. Furthermore, it's not really a "you can rewrite the engine" position at all. As I pointed out you can inline build from anything defined. There's people who inline build pascal and basic in Ruby. Ruby isn't written in either of those, and it does fine tune your application at bottle necks. That's my position.
27 May, 2010, David Haley wrote in the 106th comment:
Votes: 0
If you don't want me to infer, then say more directly what you want to say. :sad: I've been asking you for a while now and still don't understand what exactly you're trying to say. The only meaning I can get out of it is the trivialized sense. So help me out here. :thinking:
27 May, 2010, Runter wrote in the 107th comment:
Votes: 0
David Haley said:
If you don't want me to infer, then say more directly what you want to say. :sad: I've been asking you for a while now and still don't understand what exactly you're trying to say. The only meaning I can get out of it is the trivialized sense. So help me out here. :thinking:


My only point was you can optimize where it's necessary at bottle necks with low level code. Extrapolate what you will, but that's my only point–and it's what people do.
27 May, 2010, David Haley wrote in the 108th comment:
Votes: 0
OK. If what you're saying is only that in most dynamic languages, you have an FFI interface to C for writing the very performance-sensitive code in, then I have no disagreement.

That doesn't change the fact that there is clearly a distinction to be drawn between writing in C and writing in dynamic languages…
27 May, 2010, Runter wrote in the 109th comment:
Votes: 0
David Haley said:
That doesn't change the fact that there is clearly a distinction to be drawn between writing in C and writing in dynamic languages…


As I've said myself.
27 May, 2010, David Haley wrote in the 110th comment:
Votes: 0
Then I still don't really understand what you were trying to say in all these posts, because you were disagreeing with me as I said exactly that there is a distinction to be drawn between writing in C and writing in dynamic languages, even if they can embed C. :sad:
27 May, 2010, Runter wrote in the 111th comment:
Votes: 0
David Haley said:
Then I still don't really understand what you were trying to say in all these posts, because you were disagreeing with me as I said exactly that there is a distinction to be drawn between writing in C and writing in dynamic languages, even if they can embed C. :sad:


Yes, I disagree that you have no low level access as I've pointed out going on 3 or 4 times now. That has nothing to do with saying "there's no need for C" or "Ruby does everything C does." If the discussion is about shuffling bytes around at places in your own code/algorithms that you may need to often times you can in these high level languages.

I don't know why you think there has to be some great (clan destine) disagreement going on in a give and take of ideas. Pointing something like the above out puts context into statements that amount to someone saying you have no low level access when the reality is you do sometimes.
27 May, 2010, David Haley wrote in the 112th comment:
Votes: 0
I'm not sure if you're arguing with a position that I've stated and we may have been talking past each other… These high-level languages do not typically give, in and of themselves, low-level access: you must do it in C (or whatever other low-level FFI is provided to you). Do we disagree on that?
27 May, 2010, Runter wrote in the 113th comment:
Votes: 0
David Haley said:
I'm not sure if you're arguing with a position that I've stated and we may have been talking past each other… These high-level languages do not typically give, in and of themselves, low-level access: you must do it in C (or whatever other low-level FFI is provided to you). Do we disagree on that?


Yes, I agree. I just think it's important to point out that there's solutions available for some common use cases that don't involve "sucks, I didn't use C."
27 May, 2010, Koron wrote in the 114th comment:
Votes: 0
Can I tag this "The DH and Runter" thread or will someone delete that tag? Get a room, gaiz!
27 May, 2010, Runter wrote in the 115th comment:
Votes: 0
Koron said:
Can I tag this "The DH and Runter" thread or will someone delete that tag? Get a room, gaiz!


Actually, I was thinking a thread split would have been appropriate. :)
27 May, 2010, David Haley wrote in the 116th comment:
Votes: 0
I dunno, I thought that posts up to 96 and 97 were still pretty relevant, although I'd be happy to delete/move everything until posts 112 and 113.

I still think that the issues I brought up in #96 are interesting and worth further exploring, or at least people thinking about them independently for their own edification. :shrug:
27 May, 2010, Runter wrote in the 117th comment:
Votes: 0
David Haley said:
I dunno, I thought that posts up to 96 and 97 were still pretty relevant, although I'd be happy to delete/move everything until posts 112 and 113.

I still think that the issues I brought up in #96 are interesting and worth further exploring, or at least people thinking about them independently for their own edification. :shrug:


Well, yes, but for a long time this thread has been derailed. :p

"Any C++ codebases?"
27 May, 2010, David Haley wrote in the 118th comment:
Votes: 0
The nature of threads is to wander, nearly every single internet forum out there does that. If we were to complain about every time the topic strayed slightly from the literal thread topic, we'd do nothing but complain about thread wander – kind of like what's happening right now, where instead of talking about interesting ideas we're talking about conforming to thread titles.
27 May, 2010, Runter wrote in the 119th comment:
Votes: 0
David Haley said:
The nature of threads is to wander, nearly every single internet forum out there does that. If we were to complain about every time the topic strayed slightly from the literal thread topic, we'd do nothing but complain about thread wander – kind of like what's happening right now, where instead of talking about interesting ideas we're talking about conforming to thread titles.


Well, carry on, then. ;)
27 May, 2010, David Haley wrote in the 120th comment:
Votes: 0
Well, the question I asked was:
I said:
What does "framework" mean in this context? (…) So what does low-level control over your framework really mean? Does it mean controlling each byte in memory at a low level in the OS, or does it mean controlling the semantics, the OO definition itself, at a low level?


I went on to ask about whether or not control applied to semantics of the language, or to what's actually happening in the memory model.

So when one speaks of having control over a "framework", does that mean being able to control and manipulate the semantics, or the "nuts and bolts" of the memory model?
100.0/124