14 ms·
> ReasonML seems to be just sugar coating That’s exactly what it is, no secret about that, that’s the goal of that project.
by hellofunk 7y ago
> ReasonML seems to be just sugar coating
That’s exactly what it is, no secret about that, that’s the goal of that project.
- pjmlp 7y agoWhich begs the question why not learn the real deal, instead of adding another layer to debug. Programing isn't poetry.
- sshine 7y agoYou could say the same thing about Erlang and Elixir. Or Java and Kotlin / Scala. Depending on how well an alternative syntax is requested and adopted by the existing ecosystem surrounding the particular VM, YMMV. Without knowing, I think you get quite different answers in each case.
- pjmlp 7y agoI not only could, I say so. Focus on platform languages and you always win long term.
- jherdman 7y agoBecause sometimes the layer on top can express ideas more succinctly. A classic example is CoffeeScript's fat arrow syntax. It expressed a pattern in JavaScript we didn't, at the time, have a shorthand for. Example: https://coffeescript.org/#fat-arrow https://coffeescript.org/#fat-arrow
- pjmlp 7y agoAnd now it is dead, leaving behind a pile of code to rewrite in next cool toy.
- throwaway894345 7y agoIn fairness, it's dead because it was shitty and made most things harder, and the things it did improve JS copied. If OCaml fixes its syntax, then we won't have any need for Reason.
- pjmlp 7y agoThere isn't anything to fix.
- throwaway894345 7y agoIf you were right OCaml wouldn't be the only language with a popular syntax veneer.
- erichocean 7y agoTypeScript says hi.
- staticassertion 7y agoTypescript makes virtually no changes to JS syntax, except what's necessary to support types.
- erichocean 7y agoTypeScript classes, constructors and enums say hi. Talk about moving the goalposts...
- throwaway894345 7y agoNo one is moving the goalposts. TypeScript's raison d'etre is to add static typing to JS. Reason's is to fix the syntax. (Yes, TS adds new grammatical constructs, but grammatical constructs are about grammar, not syntax, contra Reason).
- 7y ago
- no_wizard 7y agoDoes Not look dead to me. last activity is within the last 30 days or so. https://github.com/jashkenas/coffeescript/ https://github.com/jashkenas/coffeescript/ Its not as popular to be certain, though.
- pjmlp 7y agoI bet Fortran and Cobol are getting more jobs offers than CoffeeScript.
- blunte 7y agoWhereby you seem to be making the case for "dead" languages.
- pjmlp 7y agoExcept Fortran and Cobol are pretty much alive, with ISO still releasing languages updates, recently LLVM got a Fortran compiler, supported by the likes of ARM and NVidia. They are just "dead" in that they are specialized programming languages with a domain of their own, that magpie developers don't find attractive to put on their CV. CoffeeScript in 2020 is just legacy code that one wants to get rid of, because some juniors found it cool to smuggle into the IT infrastructure.
- no_wizard 7y agoBased on what data is that true exactly? Opinions are fine, I don’t like CoffeeScript and never have. It’s no justification to shame someone’s choices when perfectly well working code is usable via what appears to me to be a healthily maintained tool. Less popular? Sure. Would I reach for it to start a new project? no. Calling it dead though and saying it’s only around because it’s “legacy” and only was used by “cool IT juniors” is shaming a legitimate choice without giving any context or data to back up the assertions
- toolz 7y agoI disagree, code is for and by humans. There are likely very real runtime consequences to having code that is "ugly", because the next human to touch it will value it less and do a suboptimal job. Of course all of this is highly subjective, but my understanding is that it's important to consider if you want highly successful projects.
- Gene_Parmesan 7y ago> code is for and by humans I think this is very much domain dependent. Generally the more important efficiency is, the less I find this to be true. And really, code is always for the machine at the end of the day. Additionally, if an added code layer makes the code more difficult to debug, that's also making the code worse for humans. Note I'm not arguing for or against whether that's happening in the case of OCaml/ReasonML, just making the point.
- sshine 7y ago> code is always for the machine at the end of the day On the other hand, code is read much more than it is written. You may also regard efficiency as a necessary evil if the cost is readability. Ultimately the winning strategy in this regard is achieving "free abstraction", making code that is both readable and efficient. Different languages aim at this. C++ has been best at this for most of history. Haskell and Rust are competing at this now as well. OCaml isn't exactly efficient because of free abstraction, but because of its extremely simple translation strategies. OCaml's "flambda" compiler extension wasn't released as stable until 4.03 (2016), which means that before that, very little high-level transformation was happening. My experience is that OCaml programmers care about low-level optimization, for good and for bad. For example, in this StackOverflow response there are two examples of a function 'partialsums': https://stackoverflow.com/questions/37694313/make-ocaml-function-polymorphic-for-int-lists-and-float-lists/37710287#37710287 https://stackoverflow.com/questions/37694313/make-ocaml-func... The one that Jeffrey Scofield provides is essentially more efficient because the accumulated value is a list, just like the end result, whereas my solution accumulates a tuple, which means every iteration of the fold involves boxing and unboxing that tuple. An optimizing compiler working at a higher level of abstraction might figure that out and re-use the memory of the tuple, but no sir.
- pcwalton 7y agoBecause people who know other programming languages, but not ML, might want to read your code, and it's nice if it looks familiar to them.
- pjmlp 7y agoThat is how languages like Go get designed, pour souls not able to spend some time learning.
- pcwalton 7y agoI wish Go had been a reskin of OCaml.
- terminaljunkid 7y agoThat is nowhere near their goals. Maybe if Go didn't start as a hobby project inside Google, then they /might/ even have seen some opportunity in Ocaml / Standard ML, but now that Go exists, and has a quite good toolchain, the incentive is low. Go and its foundations are radically different from a FP language like OCaml though.
- hajile 7y agoThe "real deal" here is Ocaml. It's not the most complex syntax in existence, but I'd say it's easily the most complex ML language in existence.
- throwaway894345 7y agoIf it works properly there isn't another layer to debug (and anyway, one has to debug OCaml's syntax as it is, so it's more like trading one debug layer for another). I've never had to debug into assembly before, for example. And while syntax is normally just superficial, OCaml goes out of its way to be obscure and I don't have time for that. Especially with all of its other warts (stdlib issues, crappy package management, crappy build tooling, still no multithreading, etc). I eventually just gave up. Which is too bad because the type system (absent the OO stuff) could be useful.
- deleted 7y ago[deleted]
- msla 7y agoProgramming is expressing programmer intent to the greatest extent possible given technological constraints. Sometimes, that's moving from machine code to assembly language[1]; sometimes, that's building a declarative language to express some specific logic. Finding new ways to preserve programmer intent in machine-checkable ways (that is, not just by adding comments) is one of the consistent goals of programming language design. [1] Yes, humans used to write machine code. By hand. Computers were for serious work, not mere clerical tasks such as translating mnemonic order codes to binary and doing address arithmetic.
- pjmlp 7y agoProgramming is delivering a solution that solves someone needs, typing +. or + makes zero difference solving their needs.
- mhd 7y ago> Programing isn't poetry. First time I've heard a C-like syntax described as "poetic".
- dean177 7y agoThere is no layer above, it’s not like coffeescript which compiles to another language. It’s literally an alternative syntax.
- pjmlp 7y agoSure it does, unless there is a ReasonML native compiler with its own ecosystem now.
- k__ 7y agoTrue. But the accumulation of @-signs, for example, seems to be a bit much.
- zem 7y agoreason isn't another layer, it's an alternate syntax. it doesn't compile via translation to ocaml code; both reason syntax and ocaml syntax compile to the same thing.
- baddox 7y agoNeither one is more real than the other and you really shouldn't need to do any debugging unless there are bugs in the ReasonML parser (and you could just as easily run into a bug with the Ocaml parser, but I suspect both are very unlikely).
- amw-zero 7y agoJordan Walke, the creator of Reason (also the creator of React) said that syntax is unfortunately very important, because psychologically people want something familiar. I think syntax is totally superficial, but I’m also a human who interacts with other humans. And they do not think it’s superficial. The talk where he says this: https://youtu.be/5fG_lyNuEAw https://youtu.be/5fG_lyNuEAw