Nadreamia
category: general [glöplog]
Which of their projects are you talking about? I doubt the infinite food or zero diseases "trainers" have progressed much yet at least.
I am wondering about the Naprola language. And what could the Epistome be?
Seriously I like that dude. Does anybody know him? Does his exist or is he a joke?
Seriously I like that dude. Does anybody know him? Does his exist or is he a joke?
I like him because he has a vision :)
They have a progress bar for the Naprola project. ;)
It has progressed this much:
Seriously though, the whole thing sounds like a joke to me.
It has progressed this much:
Seriously though, the whole thing sounds like a joke to me.
Quote:
Why a new language?
Presently, C and C++ are pretty good languages, and probably two of the best languages for high level programming of standard software. But there are certain problems with those languages. The four most important are:
1. High probability for bugs causing the software not to operate the way that it should.
2. High probability for security holes letting hackers and viruses attack a system.
3. They are very restrictive.
4. There are a lot of redundant tasks required of the programmer.
Yeeeeeaaaok. Allow me to illustrate my belief in this project with the following image:
Also: stop starting new idiotic threads and just email people instead.
That site have some really wacky (dis)information like:
http://www.nadreamia.com/humanoid/essays/uncrashableapi
http://www.nadreamia.com/humanoid/essays/uncrashableapi
I hope I exist!
I'm the guy from Nadreamia. Progress on Naprola is very slow. Don't expect it to be ready in less than 2 years. I've created and am using another language as a stepping stone until Naprola is ready.
To the guy who believes there is "wacky (dis)information" on my site, please let me know which part I got wrong.
I'm the guy from Nadreamia. Progress on Naprola is very slow. Don't expect it to be ready in less than 2 years. I've created and am using another language as a stepping stone until Naprola is ready.
To the guy who believes there is "wacky (dis)information" on my site, please let me know which part I got wrong.
i cant really find any sample of the language on the site, is that intended?
uncrashabe api:
layer 1 assumption: if used as documented, os apis work perfectly and never crash.
Wrong.
layer 2 is irrelevant, as it's basically the same as layer 1. Why is it even mentioned?
layer 3 assumption: all input can be perfectly validated.
Wrong.
Additionally, why not just do the validation on layer 1 and forget about this whole mess?
layer 1 assumption: if used as documented, os apis work perfectly and never crash.
Wrong.
layer 2 is irrelevant, as it's basically the same as layer 1. Why is it even mentioned?
layer 3 assumption: all input can be perfectly validated.
Wrong.
Additionally, why not just do the validation on layer 1 and forget about this whole mess?
It's also only uncrashable if the implementation of it is perfect. Well, guess what, the same goes for most APIs - but in reality all software has bugs.
There are "mathematically provable" languages, where (according to my studies at least) it's possible to prove that it's "uncrashable". Having had a quick look at such languages though, it's pretty obvious why they're thoroughly unpopular.
My take on the uncrashable api stuff is not that it's *wrong*, just that it relies on a whole bunch of assumptions about the correctness of the code so that it boils down to "To write an API that always works correctly, divide it into three layers that always work correctly."
...Even that isn't a completely useless thing to say (separation of concerns is good, mmkay?) but do you seriously think you *invented* that idea? (If so, go and do a computer science degree. You may find it enlightening.)
...Even that isn't a completely useless thing to say (separation of concerns is good, mmkay?) but do you seriously think you *invented* that idea? (If so, go and do a computer science degree. You may find it enlightening.)
more like "An API never crashes if both the code that uses it and the code underneath is correct"
Quote:
There are "mathematically provable" languages, where (according to my studies at least) it's possible to prove that it's "uncrashable". Having had a quick look at such languages though, it's pretty obvious why they're thoroughly unpopular.
Interesting. But I just had this thought: What if you actually wrote a programm with the intention to crash it? I mean,. since computers are turing machines capable of solving every problem, there will always be the opportunity that your solution will be to crash it, that your bugs will be your features, or something like that. I mean, in these uncrushable languages is it possible to write something like that just for fun, or do they really restrict you from doing any nasty thing possible to crash it?
I mean, if you really tried hard would these languages still restrict you from crashing it?
it ;)
That very much depends on the definition of "crashing".
Of course it's no problem to send your program into an infinite loop regardless of the used language and API. So, yes, crashing the application itself is perfectly possible.
The other thing is crashing by eg. null pointer or memory segmentation exceptions. This can perfectly be avoided by the right choice of OS/language/VM/API, and it is possible to write robust interfaces that handle all unexpected conditions gracefully. This is quite some work tho :)
Of course it's no problem to send your program into an infinite loop regardless of the used language and API. So, yes, crashing the application itself is perfectly possible.
The other thing is crashing by eg. null pointer or memory segmentation exceptions. This can perfectly be avoided by the right choice of OS/language/VM/API, and it is possible to write robust interfaces that handle all unexpected conditions gracefully. This is quite some work tho :)
optimus: from what I remember (which isn't much, it wasn't a subject i found at all interesting beyond the whole 'uncrashable' concept), the idea is that the program is a closed system, with a limited range of inputs. You write the program in a maths based language rather than c or whatever, and because of that you can prove mathematically that it won't crash given any combination of inputs.
I guess you could easily make it crash, but then you could prove it was crashable, so what would the point be? This stuff is used in some 'special case' situations where the system has to be bug free (like nuclear power station monitoring stuff perhaps), and I suspect the development time is waaay longer than normal, and the skills required to code seemed very high to me.
I guess you could easily make it crash, but then you could prove it was crashable, so what would the point be? This stuff is used in some 'special case' situations where the system has to be bug free (like nuclear power station monitoring stuff perhaps), and I suspect the development time is waaay longer than normal, and the skills required to code seemed very high to me.
Quote:
Of course it's no problem to send your program into an infinite loop regardless of the used language and API
As long as you assume the language is turing-complete..
Quote:
layer 1 assumption: if used as documented, os apis work perfectly and never crash.
Wrong.
I never made any assumptions about the underlying operating system. I know most OS's have bugs. If the OS has bugs and crashes, I say that it's the OS that crashed, not my code.
Quote:
layer 2 is irrelevant,... ...Why is it even mentioned?
It's mentioned because it's a part of my API. The essay is a description of an API I wrote and have been using since. My API is designed with 3 layers, so I will mention all 3 layers, even if it's just because I feel like it.
Quote:
layer 3 assumption: all input can be perfectly validated.
Wrong.
You're wrong.
Quote:
Additionally, why not just do the validation on layer 1 and forget about this whole mess?
I did it in 3 layers, because that made me able to concentrate on different goals for each layer, without having to worry about many things at once. For example, I needed extra infrastructure for the 3rd layer to be completely deterministic. That was provided by the 2nd layer. When I wrote the 2nd layer, I didn't have to think about which OS my code was going to run on, and I didn't have to worry about making everything deterministic regardless of how the user calls my functions. Due to the way in which the 1st and 2nd layers were written, and the guarantees they made, it made it very easy to write the 3rd layer. If I would've tried to do everything without those 2 bottom layers designed they way they are, it would've been much more difficult for me to do.
Quote:
"To write an API that always works correctly, divide it into three layers that always work correctly."
You don't have to divide an API into 3 layers for it to work correctly. In my essay, I'm just describing what _I_ did. There are lots of other ways to do it.
Quote:
...but do you seriously think you *invented* that idea?
I don't think it at all. Seriously or not.
216, that assumption was included in optimus' question, yes. :)
I've heard Haskell is the future...
Quote:
What if you actually wrote a programm with the intention to crash it?
When people talk about their code crashing, they usually mean that the code stops working correctly.
If you write a program to do X, and it does X, then it's doing exactly what you want it to do, therefore it is working correctly, and most people would not call that "crashing".
Quote:
in these uncrushable languages is it possible to write something like that just for fun, or do they really restrict you from doing any nasty thing possible to crash it?
If they've proven that it's impossible for something to crash, then it cannot be done, regardless of how hard you try. If you somehow manage to get it to crash, then it means they made a mistake in their original proof.