Nadreamia
category: general [glöplog]
So, uhm. If it's so wonderful, can I download sources, an SDK, or an example application...?!?
Quote:
I've heard Haskell is the future...
Haskell is a functional language that doesn't allow imperative programming. Imperative programming is what people do when they write in languages like C, Java,.. and pretty much most languages used out there.
I'm a big fan of imperative programming. I find it very intuitive and easy. There may be some instances in which some code would benefit with the use of a functional language, but most of the time, imperative is the way to go. Especially for writing regular computer programs.
do you have some code samples?
Quote:
do you have some code samples?
Code samples of what? Source code of my "Uncrashable API"?
I haven't released any code. If you're interested in seeing the source code of the API for analysis, or to use it, you can leave me your email using the form below the essay. I can then notify you if and when I decide to release it. I would need to improve the documentation of the API before I would release it. I'm very busy with other things, so don't hold your breath!
.oO(shit, meet fan)
humanoid: either that or the Naprola language
Quote:
Haskell is a functional language that doesn't allow imperative programming
as the in-house haskell guy here, my duty is to correct your misconceptions. Haskell is perfectly capable of imperative programming; in fact, it is a better imperative language than most, since it has first-class actions.
Gargaj: Naprola will not be ready for at least another 2 years.
Quote:
Haskell is perfectly capable of imperative programming;
I'm checking it out now, and I see you're right. My mistake.
Is haskell your favorite programming language?
Quote:
Is haskell your favorite programming language?
At the moment, yes.
Quote:
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.
So why not just say that you don't make any assumptions on the application that uses your API.. it's not your API that's crashes, it's the app, right? Even if it happens to crash via your API call.
The fact is, it's impossible to do anything completely reliable, due to the way things have evolved in the past couple decades. It used to be that you could buy reliability, but nobody even builds reliable hardware anymore. Nobody wants it. We just want cheap, fast, large..
So in order to make things reliable, you need to start from the assumption that things will blow up, and plan accordingly. When one bit breaks, other can pick up from there. This is something google seems to have gotten right.
Quote:
Quote:layer 3 assumption: all input can be perfectly validated.
Wrong.
You're wrong.
If your API is capable of doing anything powerful enough, you can't validate all input, as you have no idea what will happen when the input is executed, or alternatively it will just be slow. Let's say you have some kind of scripting engine that also handles data through pointers. Will you first go through all the control flow paths, validate that all the resulting pointer values map to valid memory areas, and validate all the data accessed there? What if the application prepares some of this data after giving the script to your API?
Code:
void main()
{
try
{
printf("w00t!");
} catch(...)
{
}
}
Yay! uncrashable! and in C++! :-)
I was about to write some uplifting ending note here regarding project development and cheering you to not be afraid to release things even if they're a bit unfinished for review and - who knows - so that people could join in to help you finish things faster..
but then I found [ur]http://www.nadreamia.com/information[/url] this page and realized that you're just full of it. Had I paid more attention to your site, I wouldn't have bothered to answer in the first place.
Anyway, if I'm wrong, good for you!
but then I found [ur]http://www.nadreamia.com/information[/url] this page and realized that you're just full of it. Had I paid more attention to your site, I wouldn't have bothered to answer in the first place.
Anyway, if I'm wrong, good for you!
I told you. That guy has visions! :)
I have developed a perpetual motion machine that's for sale. As of the moment, you can't see it and I'm very busy with other great things I am inventing, but do give me your e-mail and maybe I'll let you know when you can buy it if I decide to let my great secret come out to the world. It won't be cheap in any case.
P.S. I'm also working on an engine that burns water and an affordable space ship design made from common household items. And I didn't even graduate from high school!
P.S. I'm also working on an engine that burns water and an affordable space ship design made from common household items. And I didn't even graduate from high school!
I just solved world hunger.
But I will keep it a secret.
But I will keep it a secret.
![[self-ban]](https://content.pouet.net/avatars/intro.gif)
Quote:
Imperative programming is what people do when they write in languages like C, Java,.. and pretty much most languages used out there.
Absolutely wrong! Just because these languages support shaping the workflow via state changes (imperative programming) doesn't mean the least bit that "imperative programming is what people do when they write in languages like" these.
C++ supports OOP for example, now when you code in C++ no matter what do you always have to code OOP?
Of your examples C is highly capable of functional programming as well as C++. True, they don't support stuff like lambda functions out-of-the-box, but you can perfectly achieve the same effect (e.g. For C++, one might use templates to implement functional-programming idioms).
In the end, you might like imperative programming, but please do not alter the capabilities of certain languages according to what you like about them.
Quote:
P.S. I'm also working on an engine that burns water and an affordable space ship design made from common household items. And I didn't even graduate from high school!
This sounds surprisingly similar to a letter on a greek magazine about paranormal. There was some kid who had developed star trek and above star trek technology :)
Humanoid:
Just curious... how much past experience do you have of working on real-world, large-scale software projects? And have you seen one fail horribly, first-hand? The fact that you'd even *consider* to write an essay about bug-free code, when it's not released or documented yet, makes me suspect that you don't really realise just how early in the process you are.
I have no doubt that you're following all the best programming practices now, but if you can come back two years *after* you've released it to the world, added new features here and there, rewritten bits of it twenty times over to accommodate edge cases that you didn't think of when you wrote the original spec, brought in a bunch of new programmers who (as smart as they are) don't precisely share your vision and your way of doing things, and gone through the thousand and one other processes that happen to every codebase in the real world, and *still* say that you're completely confident that there are no bugs (and hey, I'm not even asking for a formal proof here)... then you might be on to something good, and you can tell us all how you did it :-)
Just curious... how much past experience do you have of working on real-world, large-scale software projects? And have you seen one fail horribly, first-hand? The fact that you'd even *consider* to write an essay about bug-free code, when it's not released or documented yet, makes me suspect that you don't really realise just how early in the process you are.
I have no doubt that you're following all the best programming practices now, but if you can come back two years *after* you've released it to the world, added new features here and there, rewritten bits of it twenty times over to accommodate edge cases that you didn't think of when you wrote the original spec, brought in a bunch of new programmers who (as smart as they are) don't precisely share your vision and your way of doing things, and gone through the thousand and one other processes that happen to every codebase in the real world, and *still* say that you're completely confident that there are no bugs (and hey, I'm not even asking for a formal proof here)... then you might be on to something good, and you can tell us all how you did it :-)
damn, i thought i was a pretty good bragger, but this humanoid guy beats everything.
also, the word "will" occurs a whole lot on that site.
also, the word "will" occurs a whole lot on that site.
I suspect this is guy is family of the mighty Adok.
-is
hmmwell that's a whole different level of clueless though. maybe adok will be like humanoid in twenty years, if he tried really (really) hard.
FUCK NOW I SEE
ITS ADOKS DAD!
ITS ADOKS DAD!
DUCK AND COVER!