C was my first love. Don’t write much of it anymore though. I’ve probably written more Ruby than anything else this year. Javascriot second. Next year I need to learn some kotlin.
C can be a nasty language but its learning curve is surprisingly gentle. The std libs are not very big, and the language itself is pretty small and easy to learn. You have to think of a lot of things you’re not used to thinking about if you use higher level languages, but C is about as close to the machine as you can possibly get other than hand writing x86.
Practically though I’d choose Rust for any medium or large project that wanted C. And I’d use C++ for everything else because it’s just an amazingly solid language, even if I think it’s incredibly ugly code.
I meant more in the sense that the library is really tiny and well documented, the syntax is easy to read and understand, etc. Of course pointers and memory allocation is tricky but malloc() and free() arent really too difficult to use either. A lot easier abstractions than what is going on under the hood, for sure
Debugging is a total nightmare though.
Not true at all. Suzzer is Java. Goofyballer probably C++ or golang or Java or something. ChrisV is C/C++ I think. Jmakin is C/shell/dev ops. Dunno about grue, but I don’t think JavaScript is his main thing. Also doubt it’s well named’s main thing. Most of my experience is php, but lately aiming for python and have done some JavaScript/node.
I am literally only javascript because I’m too lazy to do more than one thing well.
C# is good, don’t point at me
1 Like
I use it with Unity (game development engine, though I am not as yet any kind of game developer), it also supports JS and Go but most of the youtube tutorials are done in C#
After doing a few sites in React (python backend), now doing this site in Wordpress - it really sucks to watch a whole page reload when you take links.
Please quote where I insulted anyone, unless you consider calling someone a Javascript programmer an insult. Apologies if I mischaracterized the forum’s main focus, I’m just going off the fact that almost all the posts here + in the 2p2 forum are JS related. Also,
don’t know what this has to do with business programming. That usually doesn’t imply an online front end is necessary.
If you want something to be offended about, this:
is maybe encouraging advice for an amateur looking to add a skillset, but is an absolute joke of a statement for a professional programmer. GL finding a job when you ask if you can google syntax during a technical interview.
Ah, bickering just like in the old programming thread
I think the main issue is you probably don’t want to attach the event handler until after the DOM is loaded. Otherwise it appears to me that the two lines you’ve posted are equivalent, just one uses jquery and the other doesn’t. But, if #main is something that’s in the DOM very early then adding the event handler to #main via jquery.on() might work without the document ready stuff even where the first version doesn’t, just because it can actually find the element to attach the event to.
I’m imagining Discourse also has some standardized way of adding a callback for after the DOM is rendered, but it looks complicated, or like maybe the right way to do this is by creating a plugin for the sidebar, or something.
Edit: seems like maybe some use of the Ember afterRender event, but I’m not sure if you have to execute in a context like what is shown here: https://meta.discourse.org/t/help-with-client-side-event/39486
Where you’d run it after some other section is reloaded.
1 Like
I see, so this is about them enabling a content security policy. Maybe this is not a good question to ask, but could you just tweak the security policy so it will allow inline javascript? (edit: I would guess this would be a server-side change and require some kind of reload of configuration or the server)
Otherwise, the comments there are explaining roughly what I said about DOM rendering. The first will only work if the element with ID bar has already been rendered before that line of javascript executes.
The second version attaches the event to a more root element in the page (which hopefully is there). That can help because even if #bar doesn’t exist yet, the event will still work when it’s added later. I don’t think they intend you to do both, they’re just saying you should pick one or the other depending on when your script executes relative to whatever DOM element you want to manipulate. So I guess if you want to hack it up and see if you can just get something working I’d try the second version first.
1 Like
I’m not sure what actual headers are generated from that form but you might try adding 'unsafe-inline' (with single quotes) and see if it works.
Details here: CSP: script-src - HTTP | MDN
1 Like
That’s more a consequence of the underlying language not being typed, rather than of null checks. Object.keys() doesn’t preserve the type information declared for the object, and of course at run-time it’s possible that the object could contain keys not in the enum.
This seems wrong by the way:
(Object.keys(mappings)[0] as MyStringEnum).field
Object.keys(mappings) should just return an array: [‘ABC’, ‘XYZ’], neither of which will have a .field value. It seems like what you are describing is trying to get the first key, but then you’d have to use it as an index into mappings:
const k = Object.keys(mappings)[0];
console.log(mappings[k].field1);
In any case, it’s true that sometimes you have to give typescript hints about types. In this case, it doesn’t seem like you need to do too much to be able to use the return values from Object.keys to index your object. But it’s also possible to add type hints to standard functions, like this:
declare class Object {
public static keys<T>(o: { [k: string]: any}): Array<T>;
}
const keys: MyEnum[] = Object.keys<MyEnum>(MyObject);
I think there’s a better way to do this, with the keyof keyword, but I haven’t figured it out yet and it’s time to go get coffee :P
There’s an easy explaination for this problem: TypeScript sucks.
3 Likes
Interesting. I think the problem you’re having there might actually be specific to the strict null checking. I’ve never really tried to make typing as strict as what you are doing, but after spending 30 minutes my impression is that TS doesn’t deal with Enum values as indexes on types very well.
One of the things I like about typescript is that I can usually get the benefit of the typing stuff that I want, where I want it, and disable it where I don’t. But I think you are just more constrained because you’ve enabled strict null checking and we haven’t. There’s no doubt that there’s extra complexity particularly because of the compile-time vs. run-time nature of the language. This definitely seems like a case where you’re bumping up against some rough edges.
It seems like something like this should work, but it doesn’t, and it appears to have to do with the way enums work
enum MyEnum {
FOO = 'foo',
BAR = 'bar'
}
type EnumMap<K, V> = {
[k in keyof K]: V;
}
interface Fields {
field1: string,
field2: string
}
const MyObject: EnumMap<MyEnum, Fields> = {
[MyEnum.FOO]: {
field1: 'a',
field2: 'b'
},
[MyEnum.BAR]: {
field1: 'c',
field2: 'd'
}
};
declare class Object {
public static keys<T>(o: { [k in keyof T]: any}): keyof T[];
}
console.log(MyObject[Object.keys<MyEnum>(MyObject)[0]]);
I confess that pretty often I just avoid enum in favor of classes with static readonly properties. This, for example, seems to work, but I haven’t tried it with strict null checking
class MyEnum {
public static readonly FOO = 'foo';
public static readonly BAR = 'bar';
}
type EnumMap<K, V> = {
[k in keyof K]: V;
}
interface Fields {
field1: string,
field2: string
}
const MyObject: EnumMap<MyEnum, Fields> = {
[MyEnum.FOO]: {
field1: 'a',
field2: 'b'
},
[MyEnum.BAR]: {
field1: 'c',
field2: 'd'
}
};
declare class Object {
public static keys<T>(o: { [k in keyof T]: any}): keyof T[];
}
console.log(MyObject[Object.keys<MyEnum>(MyObject)[0]]);
I’m not sure what it means to “give everything a type” in plain javascript. I guess you mean never use plain old objects, instead always declaring a class and creating instances? I think that would probably get a lot of the benefit.
One of the things I appreciate is just readability of code. If I’m looking at some method in a large code base that operates on an object, and it has a type, I can easily understand what properties should exist on the object. In plain javascript it’s hard to tell sometimes what the API contract is between different parts of the same code base. It also makes it a lot easier to find all the places where something is being used, if you want to refactor. I’m not 100% sure how much of an improvement some of that is over just plain es6 + babel (which is what we’d use if we weren’t using typescript – our front end code has to be transpiled to es5), but I’ve appreciated it.
The other thing I’ve quite liked is decorators and reflection, which Angular makes a lot of use of, and which I’ve used to create API model classes that make reading/writing JSON from API requests a bit smoother, e.g.
@ApiModel()
export class Foo extends ApiBase {
@Api() public id: number;
@Api() public type: FooType; // is an enum
@Api({ write: false }) public createdAt: DateTime; // a class defined elsewhere that wraps some momentjs stuff
@Api({ write: false }) public createdBy: User; // another API model
}
The decorators and the base class can take some JSON from a server response, e.g.
{
id: 1,
type: 3,
created_at: '2019-12-10T00:14:39Z',
created_by: {
id: 2,
name: 'My User'
}
}
and create an instance of a Foo from it, also instantiating sub-objects like user:
const foo = new Foo(apiJson);
console.log(foo.createdBy.someUserModelFunction());
It also automatically creates DateTime instances, which handle some annoying things like timezone skewing and providing standard formatting options. And then the annotations also allow for a simple way to get from the class instance back to JSON to be sent to a server, i.e. foo.toApiJson().
Pretty much all of this could be done in plain JS – obviously typescript just writes a bunch of JS to make the decorators work, and uses that to figure out that it should call the User model constructor to create a new user instance when it reads the Foo JSON. But it makes it very nice to write and to read.
This sounds like a complete pain in the ass and a giant time sink.
1 Like
My feeling is that if what you’re doing works well for you, and none of the stuff in typescript sounds appealing or relevant to any actual problems you have, then you probably have made the right choice not to use it.
1 Like
One of my more recent projects was developing a C++ module for nodejs. For testing, one of my interns insisted on using TS for some weird reason. I relented, despite not really getting a clear articulation of what the benefits would be.
Man, what a mess. I really don’t like TS from my very limited interaction with it.