I can't wait to use some of the new features in our production apps. Typescript is/was my bridge into javascript development, because IMHO javascript was a broken language for a long time, and I am not sure if I could have ever done as much as I have without its existence.
Non-nullable types, tagged union types, and easy declaration file acquisition are definitely the biggest wins for me with this release.
Yeah, I'm sick of the "static types and classes!!!" crowd, too.
I've come to the conclusion that "mandatory and immutable" should be the default, but there are precious few languages in which that is the case, rather than some noise words that have to be plastered all over. (the noise words should be something like "dont_know_when_or_if" and "whacked_whenever_i_feel" for optional and mutable to make you cringe when you use such a local/parameter/return-value.
It's always funny (funny-sad) to read a project or a research paper that discovered "static types turned out not to catch as many errors as we thought it would".
We've made our turing tar pit, now we have to live in it :-(
... at least until we push the whole C-and-its-spawn edifice over the cliff.
I hear you. Compile time types can be useful, but again, I'm just weary of hearing from the people who want to make them mandatory, and seem unwilling to consider the tradeoffs.
Enter the XML config file... :-(
I ranted quite a bit lately about partial function application as well, but it's not appropriate for everything. But when when you're dealing with a crowd that has no idea that there are other ways of doing some things...
I mean, yeah. Mandatory typing isn't always The Right Thing, and XML config <english:word:grammar:adjective:insult value="sucks"/>. And it is a tradeoff.
And partial application is never necessary. It's elegant and useful, and can save you a bit of typing, yes, but it's never needed. It's nice to be able to type:
map (+ 3) a-list
but I don't mind:
(map (lambda (x) (+ x 3)) a-list)
and in most Schemes, there's a macro called cut, which means you can do this:
(map (cut + <> 3) a-list)
Which is almost as nice as the first one, and works regardless of the position of the arg you want to apply.
And it's no so much that the crowd doesn't know that there are other ways of doing things, it's that they reject them out of hand, because they're different.
Rather than strict, one at a time down to arity-1, currying, I wrote a utility to wrap up functions so "bare parens" simply called the function, or one of its partially applied "derivatives", with however many arguments you passed, and an explicit "method" on the function had to be called (I think I called it "apply", but ended up using the alias "inject" so my Java coworkers understood the purpose).
Can you attach a property list to a function in Scheme? If so, maybe you could make a way for properly prepared functions to have an "apply" property. (like I said, it's been a LONG time since I did Lisp)
My favorite Scheme has the ability, but like so much in schemeland, it's not formally specified. But cut effectively does the same thing, so what's the point?
Then again, I don't totally understand your system, so I might just have gotten it wrong...
Argh. I've never done Scheme. In fact, it's been since the mid 80s when we dabbled in Common Lisp at school. Most of this stuff I had to be re-introduced to again looking at Ruby and doing some reading about 10 years ago.
The first line looks odd to me, since there are just 3 expressions sitting there - no parens around map and the rest of the stuff. My ignorance is showing :-(
... but I don't want to write Java <= 7 style inner classes, either. I'll likely get a bad case of COBOL-fingers.
That's because Scheme doesn't support partial applications (I mean, you can return lambdas, but your functions aren't curried by default). That's why we have to cut macro from the third line to fake it.
Instead, the first line is Haskell, the best-known language to support that particular feature. I personally dislike it, but if you're demonstrating partial application, it's the language to do so.
And in case you haven't realized it yet, Java is actually the new COBOL: Verbose, ugly, and very popular in industry.
Oh, I very much realize that about Java. I was so excited about Java, 20 years ago. (of course the industry alternative was C++, so I'd rather be shot in the foot than the head).
I never saw any Simula 67 until VERY recently. Hmm. So its what Borland patterned Turbo Pascal 5.5 (and beyond) after, more or less. And Eiffel, as well. But the MIS industry keeps trying to rehabilitate a portable assembler for general application programming (C, C++, Java, ???)
...With the logic that it's performant, and it worked for Ken Thompson, not realizing that Unix is an order of magnitude less complex than the systems they're building, yes.
Don't get me wrong, as a language I will defend C to the very end (C++ and Java, not so much), but it has a specific usecase: Low-level code, or code where you absolutely need the performance. If you're not in either area, stop. You shouldn't be using C. And, of course, Rust has been eating some of C's lunch of late...
I did a lot of C in the 90s. Appropriately, in the first half to do "systems" type programming (we made development tools to emulate IBM mini computer facilities on PCs and unix , etc), less appropriately in the second half (bulk document formatting for one of the biggest print and mail houses)
One good thing about Unix is, the creators intended for things to be stitched together as insulated building blocks, NOT to be built as monolithic C programs (at least as far as I can tell). OK, I'm really off on a tangent now. Have a nice day :-)
Save the kernel, which is pretty small, yes. Essentially, they realized C wasn't up to the task of writing monoliths, and so they didn't, to keep global complexity low. Richard Gabriel argued that this was part of C's success over Lisp in "Lisp: The Good News, The Bad News, And How To Win Big," informally known as the Worse is Better paper.
One other thing: more important than the typing, is having to read excess logorrhea for the life of the project. (IDEs are good at generating filler, but I don't want to read it)
That's arguably a problem in almost every language that follows the IEEE 754 standard. It doesn't make much sense to pin that problem solely on Javascript.
when you work with floats, never expect anything to exactly equal a value, ie, it should be banned to use <float> === <constant> . That is universal across languages, for exact representations often languages provide another type. But floating point is popular because CPUs can natively work with them.
Non-nullable types, tagged union types, and easy declaration file acquisition are definitely the biggest wins for me with this release.