hopia

17 ms·

151.
by hopia 7y ago
I don't follow. What I outlined were fundamental issues with RN, not with Flutter.
152.
by hopia 7y ago
The last time I was using React Native even text input was broken on Android. It made any app using it basically unusable. Android profiler didn't work either, opening it crashed the runtime. Flutter has its bugs but they're cert
153.
by hopia 7y ago
I don't see how it's any crazier than publicly declaring React Native as their future like this.
154.
by hopia 7y ago
In my experience Flutter is not any less productive than RN is, I'd prefer the former in every case now.
155.
by hopia 7y ago
Google?
156.
by hopia 7y ago
For the record, Erlang also has an internal transactional in-memory database called Mnesia, which is essentially large-scale shared mutable state.
157.
by hopia 7y ago
In functional programming classes at the uni you probably wouldn't hear this because if they teach Haskell which I assume most do, every function always takes just one argument. That's because functions are curried by default. I p
158.
by hopia 7y ago
Approachable it certainly is, I'm not disputing that at all. The less functionally aligned a language is the more approachable it is to developers with little to no exposure to FP. Personally, learning Elixir didn't really help me
159.
by hopia 7y ago
Here I thought that's exactly the fact that makes it less ideal for learning about the functional paradigm. You also spend a considerable amount of time on Elixir learning how to architect fault tolerant concurrent systems. While usefu
160.
by hopia 7y ago
I don't really agree that Elixir is a good intro to functional languages. It doesn't really teach you much about the functional paradigm as Elixir is fairly imperative by nature. It focuses on practicality rather than adhering to
161.
by hopia 7y ago
Distributed concurrency, fault tolerance and consistent low latency are the key advantages of BEAM, the Erlang virtual machine Elixir runs on.
162.
by hopia 7y ago
Why is that? Because they both are among the only choices targeting enough platforms to be considered suitable for full-stack development?
163.
by hopia 7y ago
> That is not different from static typing. It is just that the enforcement happens at runtime. Isn't the inherent problem with dynamically typed languages exactly that they do not enforce types at compile time nor runtime? Like y
164.
by hopia 7y ago
Yeah the the very first and by now a worn out dismissal you always see is it's an academic research language, not for writing REAL software . Out of interest, what kind of software do you build with Haskell? I'm doing web stuff a
165.
by hopia 7y ago
I didn't mean to nitpick about the definitions, I just wanted to say Erlang/Elixir would both be well usable as languages even without the OTP abstractions and tooling.
166.
by hopia 7y ago
Supervisors, Genservers etc. are OTP patterns, not specifically Erlang or Elixir language features. Lumen seems to implement OTP patterns so that's why those things work on it.
167.
by hopia 7y ago
Wouldn't that depend on the platform entirely? On some platforms VM threads can be very inexpensive and are simply the right model for concurrency.
168.
by hopia 7y ago
Yes that's what I thought too. Building a bunch of data analytics microservices that host a Python API and serve the results internally to the actual outwards facing API server.
169.
by hopia 7y ago
Oh wow sounds like a pretty fundamental overhaul of the current DOM model. Then again, various virtual DOM diff implementations have shown they can improve working with the DOM a lot.
170.
by hopia 7y ago
Am I understanding this right that it's actually implementing the actor model just like Erlang? It seems to have processes and you can send them messages. The threads seem really lightweight, but how would some typical frontend benefit
171.
by hopia 7y ago
Which problem?
172.
by hopia 7y ago
I'm not so sure a multi-paradigm language is truly the ideal alternative. Languages that brag being multi-paradigm, such as Python or Javascript, in the end offer very few facilities for actual functional programming. It just doesn&#x2
173.
by hopia 7y ago
Haskell's compiler is already big and fat, having a very wide range of features. I don't think Haskell's extensibility is a problem in terms of adoption at this point, the problems lie elsewhere. Therefore, simplifying GHC de
174.
by hopia 7y ago
As for 3. Haskell already does it now with the IO monad. I can see how having something more specific for effects than the most generic IO type is the next step on an evolutionary path for languages with an advanced type system. The concern
175.
by hopia 7y ago
You're right in that you don't spend time on Haskell thinking about how the code actually executes. But I honestly don't think performance is the reason majority of the developers shy away from Haskell. Most often you achie
176.
by hopia 7y ago
Where do you put the web server? What's the purpose of it? Or you mean to use Python as the client facing API server? I meant how to architect if you use some other platform for the publicly exposed API. Would you build an internal Pyt
177.
by hopia 7y ago
I'm also curious to know how people who use Python for data science and combine it with some other platform for web facing endpoints architect their apps in the cloud.
178.
by hopia 7y ago
I've most commonly seen the description motivation chemical , which falls more in line with what the thread's first poster described.
179.
by hopia 7y ago
Agreed. I guess where it becomes a problem is when we try to find the most suitable treatment for it. I know from experience that these labels can dictate the whole treatment plan in public hospitals/clinics without much further invest
180.
by hopia 7y ago
Yeah it may be very hard to discover the actual biological mechanisms in neurological disorders particularly. But not diagnosing anything would also not resolve the problem for the patient, if there really are specific symptoms.

More ›