Re: Not gonna touch it.
More money for me, then.
Admittedly, this isn't saying much... but still!
This post has been deleted by its author
The philosophy behind TypeScript is sound; have strong typing with type checking. A common feature of many languages but not JackassScript. The execution from what little I have looked is also sound. So as an alternative to JackassScript it is sound option.
There are several languages that have been developed to generate quality JackassScript code with varying degrees of popularity and ease of use. Some basically have you write code that does not resemble JackassScript but is 'compiled' to it. While others 'extend' it by trying to have a syntax that extends it. Both are valid approaches but I think many favor the later as JackassScript is essentially a subset of the language.
Maybe your experience is different, but I've used both strongly and weakly typed languages and most bugs I've created couldn't be avoided with typing.
Typing gives better developer tooling and maybe makes it easier to understand the code in larger projects, but preventing bugs not so sure. My feeling is more that, I write a different kind of bugs in JS compared to bugs in Java. The absolute number of bugs seems constant...
Typescript I feel is the wrong solution to what might be a real problem for some larger web projects. Why I say this. Each compiler step or added indirection step added adds complexity and potential of hard to understand bugs. What really had made my code more reliable is moving to much simple programming paradigms.
Moving to class-based OOP or even procedural code with very little abstraction creates more lines of code, but also seems hugely more reliable. Especially so if its maintained by less experience/cheaper developer resources.
Its not only you: I would agree that few run time bugs are type errors. It can increase tooling sophistication, as the IDEs then "understand" more of the code.
My most productive (and favourite) language remains the dynamically typed Smalltalk (even that will barf on 1+"a" unless you specifically create a method to perform it, but it will happen at runtime.
I've had those kind of type errors at runtime, sure, but you hit them and fix them in the very early stages of testing, so I'm not sure static typing is worth the effort. Other's mileage may vary, of course.
> "JackassScript. JackassScript. JackassScript. JackassScript. JackassScript."
Oh no! You said its name five times- now it will appear and kill you.
Also, saying "JackassScript" once makes a point. Repeating it a further four times like that just looks like a contrived and unconvincing attempt to force it.
If you're on here without it you've got a pretty limited experience. I see scripts from 5 domains, though I'm only running the Reg ones. Virtually every web site these days relies on it for something, a lot don't work at all without it.
You can bitch and moan about it all you like but it is installed on pretty much every client computing device.
Besides which it's perfectly serviceable if you know what you're doing. I see shit code in C# every day. Doesn't make me hate the language, just the devs who don't know how to use it properly. It does make me wonder why people think type safety is going to improve the quality of JS in the wild.....
He's partially right that C# derived in some ways from J++, especially because Anders Hejlsberg is behind both of them, and TypeScript as well -, and obviously some ideas have been recycled when MS lost against Sun about its "Java" implementation.
That's the reason why there could be also some Pascal-ish echoes in his later works.
There's a new data type, called unknown, that differs from another catch-all data type, called any. "Unlike any, unknown is assignable to almost nothing else without a type assertion," explains Rosenwasser. "You also can’t access any properties off of an unknown, nor can you call/construct them."
In my experience, whenever there is a question, and void * is the answer, either the answer is wrong or the question is wrong.
You can just as well use an opaque structure instead of void *, it makes the code more readable and unlike void *s the compiler makes sure variables aren't passed to the wrong function.
And that works with callbacks too. You don't even need to cast it to something else in the callback code, just define the structure fully instead of opaquely in that .c file.
"You can just as well use an opaque structure instead of void *, it makes the code more readable and unlike void *s the compiler makes sure variables aren't passed to the wrong function."
Opaque structures? Wrong function? Wtf are you talking about? If its C it can't be passed to the wrong function since there's no concept of function overloading and the whole point of void is opaqueness anyway except you're not limited to a particular structure!
Nobody's talking about overloading. If you are juggling a bunch of void * variables about and calling a bunch of functions which accept void *s, or you are forced to cast to void * in the function call, you can pass the wrong variable to the wrong function. However, if you define the function to accept an opaque structure pointer instead of a void * then the compiler will enforce type checking and you can't make that mistake.
Or you don't understand why void* exists and why its sometimes required as a function parameter.
Okay, so tell me why I'm wrong and what your example is.
qsort is an unusual case, because its semantics are "operate on an array of arbitrary type". That's not a common requirement.
Dan 55 is correct in that "opaque structures", which the standard calls "pointers to incomplete struct types", are generally a superior replacement for most uses of void* in C code. void* is widely abused by C programmers who don't understand how to define ADTs in the language.
And you could certainly define an equivalent to qsort that used an incomplete struct type, or for that matter a complete one, rather than a void* parameter; but because C is not polymorphic, you'd still need to use void* in a setter for that struct (or force the caller to cast other object pointer types, which is worse), so there's no real advantage to doing so.
But there are certainly a great many instances of what the typedef-void-pointer antipattern in C:
typedef void *MyApiThing;
That's a red flag that the developer doesn't understand the language.
(Reg staff, could we please fix line spacing in PRE elements?)
I'm not historically an M$ fan by any stretch, having been a dev since the 80s, then through the first versions of IE to present, but Typescript (and to some extent, Flow, which we used for about a year before switching because of the faster feedback loop, better tooling integration and better library definitions in TS) has been a godsend for productivity.
For those who don't use it, just the benefit it provides of preventing stupid errors like "Uncaught TypeError: Cannot read property 'c' of undefined" when referencing a nested property like a.b.c is enough to make it worthwhile on any project of more than 100 lines. That, and no more Babel + plugins!
This is a good improvement.
Unknown and Any are concepts dating from 1970s in strong typed languages and used in Modula-2 in 1980s.
A variable of anonymous type (usually an array defined in the variable declaration) was not assignable directly to any apparently identical variable.
Byte was assignable to anything same size (like Any), An Array of Byte (a magic type) could be used as a parameter. Size, High and Low inside the function or procedure would allow identification of number of bytes or Array bounds safely.
Sadly Modula-2 was often taught like Pascal with no explanation of Import, Export, Opaque Modules, extra stronger typing, magic types and co-routines. I used to write DLLs in Modula-2 as my environment / compiler had no visual GUI support. The GUI part was then done in VB6.
I wrote a generic Quicksort for any type were the parameters were source & destination and a compare procedure.
You could then sort arrays, DB records or data in files (the destination being a new file), or create an index table, all according to the functionality of the Compare passed as a parameter.
There may be more to it, it was 30 years ago!
I did also use C++ from 1987, a more elegant syntax for declaring and using objects (also possible in Modula-2 as it could have private member functions), but otherwise inferior PURELY due to the AT&T insistence on C backward compatibility. If I had a fiver for every C++ program I've debugged that was really a C program with maybe an occasional "object" badly implemented.
Nice that Scripting languages have caught up with mid 1970s computer science.
Modula-2 was good also for writing device drivers even on Win32 as the libraries had named pipes and all NT security features.
If only the picture of the article contained a script and not a marked-up page. This is an IT blog, people notice these things.
Biting the hand that feeds IT © 1998–2020