Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MorleyDev]

The (only?) redeeming part about Javascript is that it teaches you how great callback functions are :v I find that I never ever make my own classes, since it's easier to treat everything as a plain old data object and put the logic in the functions. This is especially true with Underscore.js, which gives you all the nice functions you expect from using Python, like zip() and map() and each() <since for (x in y) in JS is pretty weird> ...

Actually a lot of those are in the Javascript standard now. map, filter, forEach are in ES5 (so IE9+) and checks like every and some are in ES6 (Only the bleeding edge browsers atm). I find I don't need underscore/lodash as much now that those exist (See the MDN on Array for full list). Promises are in ES6 too, which I find work a lot better than callbacks for complex asynchronous operations (as callback hell is very real).

I almost never work on a JS project nowadays without es5-shim and es6-shim to add all the shiny new goodness back to older browsers (How I learnt to embrace the madness and start using Promises in IE6).

Though actually, I tend to use Typescript instead whenever possible and managed to make headway with pushing this onto my colleagues at the office even, partly so we can use the ES6 language features like modules, arrow functions, classes (TS even allows for you to specify protected and private access scope).

And of course, partly because I am of the opinion that explicit typing is what makes working on an enterprise-level project that involves more than one developer not sanity-shattering or documentation-heavy (Functions can actually self-document what parameters they expect so you don't need to write a 5 paragraph write-up of every function in a project).

When you aren't being strict about it, standard Javascript is great for quick-and-dirty work. But for proper long-term maintainable projects, you need more rigour than the language can give you.

[jaked122]

Yeah, the main reason I can't use languages with duck typing is that they don't really work without intimate knowledge of the idiomatic way of doing things.


I like not having to know that, other than maintaining code style.

[Skyrunner]

I can't tell how a Promise is different to a callback function...

Also I wish svg had an easy way to resize text to fit in a box :/

[jaked122]

I can't tell how a Promise is different to a callback function...

Also I wish svg had an easy way to resize text to fit in a box :/

A promise is a callback function. It's really just the same mechanism with a different name, I think sometimes they also call it a Future.


Cause you know, you can have a future.

[Telgin]

Promises are just syntactic sugar for callbacks.  They're primarily a means of avoiding callbacks stacking up 10 levels deep and indenting your code to crazy levels.

Something like this:

Code: [Select]

orm.model1.find({}, function(error, records) {
    orm.model2.find({}, function(error, records2) {
        orm.model3.find({}, function(error, records3) {
        });
    });
});

becomes this:

Code: [Select]

orm.model1.find({}).then(function(records) {
    return orm.model2.find({});
}).then(function(records2) {
    return orm.model3.find({});
}).then(function(records3) {
});

All neat and only one function level deep.  Imagine if you needed 5 or more levels.  Of course, it does get trickier if you need to manage return values of some of the previous callbacks in later callbacks.  The other benefit though, is that you can tack a .catch() at the end of it all and avoid having to check for errors at every single callback.  If they return an error as a conventional callback, they can now just throw an exception and be handled by the .catch() function.

[Skyrunner]

Oh huh, that seems pretty neat.

[MorleyDev]

Yeah, they're a syntactical sugar. But a really nice one, ya know. Forces the async code to look more procedural, which definitely helps with readability. C++ has futures and promises (long story behind that one), and C# has Tasks (and async and await). All serve the same basic functionality.

Also helps avoid a really subtle bug that has been found in some pretty major projects in the past:

Code: [Select]

function tryreadFile(callback) {
    fs.readFile("./something.txt", function (err, data) {
       if (err) {
           console.error(err);
           callback(false);
       }
       console.log(data);
       callback(true);
    });
}

Trivial example there, but it's very easy to forget to return at the right moments in a callback. Especially when you're a few levels deep. In theory proper TDD will catch those errors, but Promises are a nice way of reducing the cognitive burden by meaning you don't even need to think about it.

[Dutrius]

So, I had the "bright" idea to clone DF (or at least a heavily simplified version of it. Maybe an early 2D version) and stick it on iPad.

By Armok, what was I thinking? I don't have anywhere near the experience to pull this off. I don't know if something built in Visual Studio will even run on an iPad.


I don't even have an iPad.

[TheBiggerFish]

So, I had the "bright" idea to clone DF (or at least a heavily simplified version of it. Maybe an early 2D version) and stick it on iPad.

By Armok, what was I thinking? I don't have anywhere near the experience to pull this off. I don't know if something built in Visual Studio will even run on an iPad.


I don't even have an iPad.

It's the Bay12 Signal!  Someone's run into a modding problem!  Quickly!  To the !!MAGMA!!mobile!
(Yeah, I have no idea either.  Although Android runs Linux and you can run DF on that, right?)

[Arx]

Android apps are written in a specific variety of Java. I don't know about iOS apps, but you'd have to pay to get one onto the app store anyway.

[TheBiggerFish]

Android apps are written in a specific variety of Java. I don't know about iOS apps, but you'd have to pay to get one onto the app store anyway.

Yes,  but the actual device, under that, runs a flavor of Linux, right?

[Putnam]

IIRC iOS is Objective-C or something hilarious like that

So, I had the "bright" idea to clone DF (or at least a heavily simplified version of it. Maybe an early 2D version) and stick it on iPad.

By Armok, what was I thinking? I don't have anywhere near the experience to pull this off. I don't know if something built in Visual Studio will even run on an iPad.


I don't even have an iPad.

It's the Bay12 Signal!  Someone's run into a modding problem!  Quickly!  To the !!MAGMA!!mobile!
(Yeah, I have no idea either.  Although Android runs Linux and you can run DF on that, right?)

this is not a modding problem

all i can say is

good luck sucker ahaHAHA

[Arx]

Android apps are written in a specific variety of Java. I don't know about iOS apps, but you'd have to pay to get one onto the app store anyway.

Yes,  but the actual drvice, under that, runs a flavor of Linux, right?

E-eh. I don't know if I'd go that far (UNIX might be more accurate), because whilst I think it may be true in the strictest sense it's probably about as closely related to common distros of Linux as MacOS or whatever Macs run is.

It's possible to play DF on a tablet if you SSH into a PC, though.

[TheBiggerFish]

Android apps are written in a specific variety of Java. I don't know about iOS apps, but you'd have to pay to get one onto the app store anyway.

Yes,  but the actual drvice, under that, runs a flavor of Linux, right?

E-eh. I don't know if I'd go that far (UNIX might be more accurate), because whilst I think it may be true in the strictest sense it's probably about as closely related to common distros of Linux as MacOS or whatever Macs run is.

It's possible to play DF on a tablet if you SSH into a PC, though.

It's worth a shot though.

[Bauglir]

simply decompile the DF executable

then write a program that will determine a set of instructions in the appropriate ios language to produce the equivalent assembly

what could go wrong