4 ms·
It’s amazing how many developers are personally offended (and I’m not suggesting the author is) when a technology resists them trying to be “clever”. Those same
by yakshaving_jgt 5y ago
It’s amazing how many developers are personally offended (and I’m not suggesting the author is) when a technology resists them trying to be “clever”. Those same developers might also pay lip service to the idea of writing simple code, because that’s the most mature thing to do, and yet one of the most common criticisms of Elm is that it doesn’t let you try to be clever and do synchronous IO.
That’s a good thing. A very good thing. You can trust the code you write [to a reasonable extent]. You can trust the code your colleagues write [to a reasonable extent], even if they’re relatively junior. Not every change needs to be interrogated like you might have to in the foot-gun factory that is JavaScript.
This level of predictability is amazing for a business, and consequently amazing for a developer’s circadian rhythm if only they could see further than their nose.
- davnn 5y agoSimplicity is extremely undervalued in my opinion. I was previously an evangelist for functional programming with Scala et al., but as my experience grows I become more and more utilitarian. The saying „ With great power comes great responsibility“ fits pretty well in the context of programming languages imho.
- dnautics 5y agoThat's surprising to me because I would think of scala (and Erlang, elixir etc) as utilitarian fp languages, I refer to them as "working persons languages".
- mhitza 5y agoWhen prototyping I prefer dynamic languages because they allow partial/"sloppy" programs, as generally you type code along the happy path first. Personally I think it wouldn't hurt if more strongly/statically typed languages took a note from the GHC compiler and had an option like -fdefer-type-errors[1]. That way one can write the sloppy/clever/prototype code, then disable the flag and make the program sturdy in the presence of failure. [1] https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_gui...
- yakshaving_jgt 5y agoHave you ever leaned on deferring type errors to any significant extent? I’ve been writing Haskell primarily for several years and I tested it out maybe once or twice briefly, but otherwise haven’t found the utility.
- mhitza 5y agoI've only used Haskell to experiment with small, gui, command line, networked projects and within that context I did have those flags enabled (deferer type errors and typed holes both proved helpful). However I've recently switched to chicken scheme for that purpose, not because Haskell isn't good but because of type friction I encounter when trying to use new libraries. It's not a rant at Haskell, as I assume were I to use it on a daily basis it would be a nice fit. But as I'm using it a couple of times a year, it doesn't work out.
- lionsdan 5y ago> small, gui, command line, networked projects ... switched to chicken scheme for that purpose What's your preferred gui library for Chicken for this sort of thing?
- mhitza 5y agoNo GUI library used thus far, but since I'm using Linux as my target machine for these things it's probably going to be Gtk. Might write my own helper library on top of some raw FFI bindings.
- danidiaz 5y agoA recent video about -fdefer-type-errors: https://www.youtube.com/watch?v=hPVjA3TO9OI https://www.youtube.com/watch?v=hPVjA3TO9OI
- cies 5y agoI prefer the dynamic langs for their "compile" (maybe more accurately "interpret") speed. It helps to keep short change-recompile-reload-check loops during development.