71–80 of 81 posts
I really want to like Elm. When I'm writing JS/React code, I sometimes think "this would be so much nicer in Elm!" - especially for architectural issues. But the few times I’ve actually tried doing something in it, I find that the parts of what I want to do that fit cleanly within Elm’s walls are really nice, but the parts that don’t quite fit get hard quickly. Suppose I want to do something with the DOM that doesn’t…
I really want to like Elm. When I'm writing JS/React code, I sometimes think "this would be so much nicer in Elm!" - especially for architectural issues. But the few times I’ve actually tried doing something in it, I find that the parts of what I want to do that fit cleanly within Elm’s walls are really nice, but the parts that don’t quite fit get hard quickly. Suppose I want to do something with the DOM that doesn’t…
I totally understand that DOM access is a pain point for Elm developers right now. I often run into that issue myself. But declaring a port is a small price to pay for the all that the Elm compiler gives you. When I have to refactor a React/Redux app, I absolutely dread it. With Elm, I love it, even if the project is older or unfamiliar.
I really want to like Elm. When I'm writing JS/React code, I sometimes think "this would be so much nicer in Elm!" - especially for architectural issues. But the few times I’ve actually tried doing something in it, I find that the parts of what I want to do that fit cleanly within Elm’s walls are really nice, but the parts that don’t quite fit get hard quickly. Suppose I want to do something with the DOM that doesn’t…
Similar experience. Once you get to grids and calendar controls it is a hassle with no clear path. I think two things are require for to solve this: 1. Some way to make it easy to drop in components into an existing view. Global state makes this hard, but it may be possible with some of Haskell's funky features, or even just type classes. 2. With the above we just need people to write some basic controls for Elm and…
I really want to like Elm. When I'm writing JS/React code, I sometimes think "this would be so much nicer in Elm!" - especially for architectural issues. But the few times I’ve actually tried doing something in it, I find that the parts of what I want to do that fit cleanly within Elm’s walls are really nice, but the parts that don’t quite fit get hard quickly. Suppose I want to do something with the DOM that doesn’t…
While it's easier to bang out code with React, you have to acknowledge the massive downside of that flexibility: you have zero guarantees that your code will work properly. Even if you use Typescript or Flow you still you won't have the guaruntee that your code accidentally "fire the missiles", because JavaScript is not a pure language. I totally understand that DOM access is a pain point for Elm developers right now…
Earlier quoted context omitted.
A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28p... ) There's a very good example in C++ of how this caus…
The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.
Earlier quoted context omitted.
Does lambda calculus have character strings, structures, exceptions, symbols, mutable variables, quoting code as data, macros and three different kinds of object equality?
it does have symbols
Some of the algorithms for reducing lambda expressions are symbolic, like, say, alpha reduction. But they are not done in lambda calculus itself, as far as I can see; they are done on lambda calculus (by the mathematician, or a machine for manipulating lambda calculus terms).
Analogy: just like ordinary algebra doesn't have symbols; but of course mathematicians work with symbols and so do computer algebra systems.
Since lambda calculus is Turing complete, it can of course represent lambda calculus manipulation (via Goedel numbering of lambda terms and then working with their arithmetic encoding as Church numerals, or whatever).
Earlier quoted context omitted.
The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.
I think that's a coding style decision, and shouldn't be part of language specification. I certainly don't feel about primes the way you do: having a function f and a function f' usually means they are sort of similar with some specific difference between them, definitely not "couldn't think of a better name". E.g., in haskell a prime often denotes a strict function, it's a better convention than having f and f_stric…
Edit: Plus, then you don't have to wonder if that particular function follows that naming convention; prime meaning strict isn't nearly as universally followed as ? or ! in Scheme, for instance.
Earlier quoted context omitted.
This is what I find troubling about Elm. The creators see it appropriate to enforce their strange preferences with dubious reasoning. The enforcement (in standard Elm format) of a 4-sized tab[1] is just another example. Like you said I'd not have the language community enforce what is acceptable down my throat, and that conflict of preferences within a team is best solved by making style guidelines instead of having…
I completely agree with you. Evan isn't happy just controlling what packages you can publish that use the native api on package.elm-lang.org, or what you can do in the language since the removal of signals, he wants to control even minute things like whether you use a fucking prime in a function name in your own code. It's ridiculous.
Earlier quoted context omitted.
A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28p... ) There's a very good example in C++ of how this caus…
The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.
Earlier quoted context omitted.
Similar experience. Once you get to grids and calendar controls it is a hassle with no clear path. I think two things are require for to solve this: 1. Some way to make it easy to drop in components into an existing view. Global state makes this hard, but it may be possible with some of Haskell's funky features, or even just type classes. 2. With the above we just need people to write some basic controls for Elm and…
They really seem to be staying in the global state camp. I find it impractical too, but it would make their "time travelling debugger" and other similar tooling stop to work if components could have local state.
An example is a calendar control, in a grid control in a tab. You click right to go to the next month. That event needs to be bubbled through layers of boilerplate code to direct it back to the calendar's view.
Also another consequence is that the model is a mix of business data and UI state data. The selected month shouldn't affect the business logic, but it is bundled with THAT data which is annoying.
Not sure what the solutions are though.