181–190 of 246 posts
Earlier quoted context omitted.
Give it another year and the new batch of hotshot developers will reinvent static typing and perhaps one or two other features from the 1970s, but it'll have some cool name and only implement 50% of the functionality.
"This will be the sixth time we have reinvented basic programming, and we have become exceedingly efficient at it."
Earlier quoted context omitted.
"This will be the sixth time we have reinvented basic programming, and we have become exceedingly efficient at it."
What is that a reference to?
Earlier quoted context omitted.
It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…
You build your system as a box that takes strings in and sends strings out. You then have to do a bunch of checks (as part of your de/serializing) at the boundaries only . Inside the box, all your logic and transformations are type safe, and indeed you can turn some logic issues into mechanically checked type-level issues, which are basically free unit tests.
Earlier quoted context omitted.
Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.
Well, I find that when my C++ compiles When I first learned Java, still in my undergrad, my first impression (and nearly everybody's) was that when it compiles it works. It was still more work than Perl, Lisp, Prolog, and everything, but didn't require the annoying C debugging cycle. But, anyway, all that is kids play near Haskell.
The two idioms are 'child's play' & 'next to'. The words are correct synonyms but the usage is unusual enough that I read as having a totally different meaning my first time.
Earlier quoted context omitted.
Then you'll probably be very excited to read about http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Pro...
Well, BEAM has supervisors, supervision trees, loads of support for fault tolerance, automatic usage of multiple cores, and it easily scales to multiple nodes as well. Simple actor-based concurrency is possible in many languages. Also, even if Elm were to get all that stuff, it'd still be compiling to JavaScript and aimed at web apps. (Don't get me wrong, I'm super excited to see Elm getting support for message-passi…
Earlier quoted context omitted.
You might be interested in the Crystal language. It's a statically-typed, Object-oriented, Ruby inspired language. It's Ruby with types, basically. You might also be interested in Elixir which ties in to the Erlang ecosystem, but if you are super into OOP (like me) you might find it slightly more difficult, but since you have experience with static-types, you probably know some FP stuff, and so it's not that bad. Eit…
It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…
Here are a couple of other under-appreciated facts about compilers:
1. For regular grammars, they are easy to build with any kind of programming language.
2. For regular grammars, they are really really easy to build with statically-typed programming languages.
Now days, my web development is essentially just compiler construction for regular languages, and it just so happens that extremely statically-typed like the MLs (F#, in my case) are damn good for writing compilers (one joke is that it’s the only thing they’re good for). I write far fewer lines of code per feature than I ever did with ”dynamically“ typed languages like PHP, and it’s usually right the first time.
What I really want is a language with Elm's type system, simplicity, and syntax, but aimed for backend software instead of HTML apps and with strong support for an Erlang-style actor model of multicore, distributed concurrency. Basically something like Elixir, but with Elm's syntax and type safety. In the meantime Elixir will do for me, but I'd really like more type safety without going full Haskell.
Did you try dialyzer for Erlang[1] or Elixir[2]? [1]: http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html [2]: http://elixir-lang.org/docs/stable/elixir/typespecs.html Not sure it helps, it's on my todo list.
@spec foo[a: SomeProtocol & SomeBehaviour](a, a) :: a
Also, I'm still new to FP, so if you go outside of the Elm architecture, you're going to run into problems, which you're use to solving with specific tools, but they won't be available. So you'll have to spend time learning how to compose things in a new way.
Has the elm installation on Linux improved in recent months? Last time I tried my system's GHC was too new to install it from source and the node installation went kablooey in weird parts(too recent ncurses, the automatic "reactor" browser repl not finding the Html package etc...)
So, is it still true to say, "You wish you could express your business logic with pure functions. But often you can't because the lack of immutability hurts performance in various ways. But ELM creates a 'sandbox' in which you can do so, by letting you write functions which work over time varying streams instead of stateful callbacks." If not, which parts changed / how would you revise it?
It's more that real programs need real effects: you need to send HTTP requests, read from user input, etc. Elm gives you a managed way to deal with those effects, while keeping the program declarative, and making as much of the logic side-effect free as is possible.