u/qwe1234

rofl, didn't help much, did it

the future of the book is a video game?

fuck all that, fuck all that to hell.

eagerly waiting for the inevitable crash.

it will be sweet.

calibre is pretty shitty software.

the fact that your particular backwater prefers a crappy standard for e-books is irrelevant.

i'm betting that there are more books in the fb2 format in the world than in any other e-book specific format.

by number of books fb2 is certainly the most popular standard, 'homegrown' or not. whether or not publishing companies prefer it or not is irrelevant; we're talking about file format popularity, not 'money made per file'.

p.s. i'm ommiting pdf as it's not specific for e-books, but there are probably an order of magnitude more e-books in pdf format than in anything else.

the world's most popular e-book format is fb2.

of which this author doesn't even mention in his post, which kinda tells you about his qualifications to speak on the matter.

there's this amazing 20th-century technology called "instant messaging". you should look into it, it's amazing space-age technology.

get this shit off my internet, you scum.

"maemo sdk" is just a pre-packaged cross-compiling gcc build, for easy installation.

maemo is just another linux distribution, not some sort of separate 'mobile os'. in reality there is nothing in 'meego' that wasn't going to be there in 'maemo 6' anyways. so 'meego' == 'maemo 6'.

that's not what my saying is, you fucktard.

no, you're confused. (also, what maemo sdk?? maemo is just a regular old linux distribution. there is no sdk.)

maemo version 6 has been rebranded as 'meego'. (for marketing reasons, i guess.)

so yes, it exists.

"North America" is like 5% of the world market.

enjoy your walled garden and shitty apple crap.

thank you for at least admitting your own ignorance.

citation: "yo'momma is a so slutty she got more clap than an auditorium".

have a nice day and please refrain from posting braindead shit in the future.

You don't know what you are talking about. Treadmill collection still requires a full traversal of objects in memory, and thus isn't suitable for real-time.

(Unless you meant something else by 'treadmill collector', in which case you'd better give a descent citation with working code.)

refcounting isn't a joke. refcounting is the only method available for real-time software, you idiot.

fuck you

math doesn't formalize anything, it's just a notation.

if your thinking isn't clear and formal in the first place, then you're just using math for bullshit and obfuscation. you should be burned at the stake for this.

But switching between threads is costly

that's retarded bullshit. get the fuck off my internet, you idiot.

it all boils down to mutable state and sequencing, though.

no matter how many layers of abstraction you pile on, it's all just lipstick on pig that covering up the ugly truth.

and the ugly truth is: no matter what you do, no matter what kind of abstraction you use, it's still mutable state and sequencing in the end. moreover, it is this mutable state and sequencing that is the irreducible complexity which you cannot ever, ever not have to deal with.

You told me that everything I described could be done in your programming language, too.

Anyway, I've tried explaining the concepts to you and your responses show a remarkable lack of depth of thought.

using basic logic i can deduce from those two statements that your 'concepts' are devoid of practical use.

pray tell, what's the point of these 'concepts' of yours if their only use is to obfuscate something that is trivial without them anyways?

I have read about structured programming. It's pretty uninteresting.

exactly my point. if 'structured programming' is uninteresting, then 'monads' are doubly so, since they are equivalent.

i wasn't talking about turing-equivalence. where you got that is beyond me.

the point is that the physical universe can work in one and only one way: mutable state and sequencing.

and for mutable state and sequencing the ultimate, one and only abstraction toolset has already been invented. read up on dijkstra, 'structured programming' and formal verification.

anything else (including 'monads') is putting ridiculous chocolate coating on the same old turd.

p.s. and that's exactly why programming is hard: the physical laws of nature force you to deal with mutable state and sequencing.

all your examples are more than trivial in imperative languages.

your first example is just a 'for' loop. (congratulations, you needed category theory to reinvent looping. dijkstra must be spinning in his grave like a turboprop.)

I guess STM is more academic wankery though, as true programmers use threads and locks when they need to do concurrent or parallel programming, don't they.

in case you haven't noticed -- STM is locks and threads.

also, stm or something like it is trivial to implement in e.g. c++. (and no, you don't need to create a special sublanguage.) you don't need monads, all you need is support for pre-/post-conditions in your language.

In most languages adding option types makes things more painful as you need to explicitly deal with what happens if any of the computations fails. However, sequencing in the Maybe monad does exactly what you'd expect to happen. If the first one fails, the entire thing fails, and if not it passes onto the next one, and if that fails the whole thing fails, and so on.

utter bullshit. you just described exception handling. all normal imperative languages have supported exception handling since forever.

So some monads are about passing state around, but others are about fundamentally different notions of computation like the nondeterminism and query stuff

bullshit. there's only one 'notion of computation', one and only one from now till the end of time: mutable state and sequencing. sorry, but that's just how the universe works.

p.s. read up on 'structured programming'. it's all been done before. just because you put some mathematical notation lipstick on that pig doesn't mean you actually solved the problem.

examples, please.

the mathematical 'properties' (i hesitate to use such a big word for such a trivial concept) are exactly the same for monads as they are for 'semicolons' in an imperative programming language.

if it takes category theory to explain to you how imperative programming languages work -- fine, good for you. it's your problem, though. the rest of us normal people don't need category theory and we already know how imperative programming works.

in closing: yes, i'm 100% sure that there isn't a single difference between 'monads' in haskell and 'statements' in imperative languages. everything you can do with 'monads' you can also automatically transcribe 1-to-1 with imperative programming features.

p.p.s. academics make up words like 'monads' because they a) don't know shit about programming while at the same time b) they know a bit of math theory. they use this math theory as a crutch, to help them come to terms and understand how imperative programming works. (because they are that bad at programming.)