5 ms·
When working with functional languages (my current choice is Scala), I do feel that they require a level of mastery that "traditional" imperative languages do n
by hvs 10y ago
When working with functional languages (my current choice is Scala), I do feel that they require a level of mastery that "traditional" imperative languages do not. I also feel that if computer science/software engineering is ever going to gain any sort of repeatability it will be through functional design.
That said, functional programming is incredibly difficult to do well without years of practice and the languages still suffer from limitations with performance that are hard to debug. While I still feel that functional programming is the "future" of software engineering, I feel it is quite a ways in the future.
- stephen123 10y agoWith time travel debuggers being the notable exception, where FP is enabling much better debugging. http://debug.elm-lang.org/ http://debug.elm-lang.org/ as one example.
- Sean1708 10y agoMaybe I'm missing something, but how is that different to something like rr[0]? [0]: http://rr-project.org/ http://rr-project.org/
- dkoontz 10y agoFrom the rr site: Remember, you're debugging the recorded trace deterministically; not a live, nondeterministic execution. The replayed execution's address spaces, register contents, syscall data etc are exactly the same in every run. Elm's debugger (and similar projects like the Pux debugger from PureScript-land) are live systems. They are replaying all events deterministically but you can edit your code, reload it and then replay the exact same series of events or toggle events on/off and see what the resulting state is. rr is super cool and I'm very glad it exists but it's a static analysis tool where the Elm debugger is almost REPL-like in terms of how you can play with things and see the results live.
- deleted 10y ago[deleted]