181–190 of 254 posts
Earlier quoted context omitted.
With JavaScript being the most used language in the world I highly doubt the old stereotypes still apply
Is it the most used language in the world? Seems like I keep hearing comments like that, but the rankings I've seen don't list it that way.
Earlier quoted context omitted.
Is it the most used language in the world? Seems like I keep hearing comments like that, but the rankings I've seen don't list it that way.
What rankings have you been seeing? Javascript is on top of the list from what I've been seeing. https://insights.stackoverflow.com/survey/2018/#technology
Earlier quoted context omitted.
It's certainly been my experience that there are a lot of JS developers who aren't like you, though I have met a few who are. But JS has traditionally been one of the most accessible languages. Before transpilers became common, view source allowed non-programmers to learn javascript by example. And because of it's use in the front-end/web, you saw a lot graphic designers and other non-programmers learn it to be able…
> Javascript also goes out of its way to be friendlier. While other languages complain when you try to add two different width integers, Javascript will happily add a number and a string together. It's something that drives those of us with a static typing background nuts, but makes the language more approachable overall. We have differing definitions of friendly. Since I understand types and operator overloading, I…
I think it's a bit of a wolf in sheep's clothing. It makes it harder to master, but less intimidating when you're first starting out.
Also, I probably shouldn't have used the term static typing, since the issues I'm talking about are more associated with weak typing rather than dynamic typing.
Looking at this as someone who's been writing a lot of ClojureScript lately, I'm reminded of how nice it is to be writing in a Lisp: if I felt this was the right syntactic construct for a common-enough problem in my codebase, I'd write a macro for it and get on with my life without having to wait for it to trickle through committees, compilers, and browser implementations.
The benefit is that your polyfill/conversion to something browsers support today is handled by someone else, and your actual code base can point a reader to the proposal to at least make some sense later on.
Not that I imagine many people would encourage using a stage 0 proposal, but it's probably a bit better than everyone writing their own adhoc implementation.
Earlier quoted context omitted.
Yes, but I think the other point is well-made, as well: languages that allow this can be very difficult to work in if you have to maintain a large app with multiple contributors over a long period of time.
The same can be said for function calls, with the indirection they create hiding details of broken and side-effecting implementations. None the less, the opposite is also true. Languages that have macro facilities can aid in writing more legible code. (See `threading` in clojure), or the `loop` macro and regular expression macros in common lisp.
Some people are just terrified of any new abstractions, I guess, preferring to work with an endless series of tally marks, rather than these obfuscating “multiplication” and “exponent” complications (exaggerating to make a point - abstract != unintelligible).
Earlier quoted context omitted.
What rankings have you been seeing? Javascript is on top of the list from what I've been seeing. https://insights.stackoverflow.com/survey/2018/#technology
Tiobe index for one. But I just searched Google and checked the top few.
Earlier quoted context omitted.
AFAIK pattern-matching is not a historical Lisp feature, it's usually been limited to simple destructuring. In the modern acception of tree patterns (as opposed to text patterns aka regular expressions), I guess it comes from ML (and possibly prolog but prolog's unification goes even further?): it doesn't look like ISWIM had tree patterns and I can't find older references.
In Lisp pattern-based programming has been first implemented in 1962 in by D.Bobrow (METEOR). From then on there are many implementations of pattern matching in Lisp based software, from Planner, to rule-based systems, LISP70 (Tesler, ...)...
I was going to specialize in AI in my major, but I guess it was about 25 years too early. But that’s another tangent.
Earlier quoted context omitted.
Method-based syntax for pattern matching is easier to read and grok (IMO), but it lacks the dynamic capabilities of data-oriented syntax (in Kasai, patterns can be built/manipulated at runtime). It's interesting to compare the two approaches.
If you mean by method-based pattern matching that you evaluate a function for each 'case'. My lib can do that do: const match = require('pmatch-js') const _ = require('lodash') const fizzbuzz = x => match(x) .when(a => a % 3 == 0 && a % 5 == 0, 'fizzbuzz') .when(a => a % 5 == 0, 'buzz') .when(a => a % 3 == 0, 'fizz') .otherwise(a => a) console.log( _.range(1, 101).map(fizzbuzz).join(' ') ) But maybe you mean somethin…
[...Array(100).keys()].map(v=>v+1)
So the proposal is super confusing to me (but I hadn't seen match before). At first I thought it had something to do with regex. Essentially it's a switch variant that is (a) confusingly named 'match' (bad) (b) returns a value (good?) (c) and is actually a kind of function (wha?), since it (d) supports recursion, but (e) doesn't require break (good), (f) looks like a bag of inline functions but isn't (bad). How about…
Love this comment; reminds me of what I thought when I first encountered pattern matching. a. Yup, that's what it's called in OCaml, Scala, F#, etc. Might be a little confusing at first, but it's all about finding a "match" for your value, which is different from a guard in an "if" or a "switch". In an "if", you need to provide a boolean (or a value coercible to a boolean). In a "switch" you don't provide the boolean…
Switch can also be implemented as a jump table in some cases.
Earlier quoted context omitted.
Let's see an example of your proposed alternative syntax.
Here you are: var x = match (response) { case { status:200 }: true; case { status: 404 }: new NotFoundError; case Number: Math.PI; case SomeClass: 1; case /^http/: "http error"; default: -1; };
When reading the code, that means you need to hunt for the match or switch statement to know what happens at the end of a case clause.
IMO, if one is willing to correct historical errors, even if they are engrained, Apple’s Swift language makes the best choice here. It requires an explicit fallthrough to fall through to the following case, and goes even further than what you propose by only having a switch keyword (https://developer.apple.com/library/content/documentation/Sw...)