mustermannBB

6 ms·

1.
by mustermannBB 1y ago
Correct me if I'm wrong but a big part of the value proposition these days for Erlang/Elixir would be that it comes build in with a lot of the tools that other runtimes would require. For example a message bus is kinda integrated
2.
by mustermannBB 1y ago
All fair. I suppose my point is that I think people do actually have a decent sense of what value proposition there with emacs but simply don't agree that its strengths are worth the steep climb and or a the much better that their curr
3.
by mustermannBB 1y ago
Problem with Hare is that it is (or at least was last time I checked) Linux/Unix only and so by design. That kinda makes it DOA for many.
4.
by mustermannBB 1y ago
I think it is way simpler than that. IMHO, for many people young or old the value proposition of emacs simple is no longer there and/or worth the huge learning curve. For most things people would use something like emacs the alternativ
5.
by mustermannBB 1y ago
Are you comparing Elixir with a framework as extensive as Phoenix to Go and "just" its standard http library? If so I'm not sure that would be a good comparison then.
6.
by mustermannBB 2y ago
Or they simply think or know that vscode does what it needs to, for them to get the job done. In the end the best tool is the one you can be productive in. No need for gatekkeeping about something as trivial as ones preferred editor or IDE.
7.
by mustermannBB 2y ago
To some vscode probably is good enough and that is OK. I don't see why this would be an issue.
8.
by mustermannBB 2y ago
To be fair the importance for devs/programmers to touch type is often very exaggerated. Not saying it is not a benefit but is is far from a "must" or something that is a detriment to producing quality work. In the days where
9.
by mustermannBB 2y ago
I mean it depends what one use Vim or their editor of choice for. For example I do think that efficiency gains when for example developing in Java are marginal if there at all. Or for people who do not hate the mouse, or people who can&#x27
10.
by mustermannBB 2y ago
What real world application is there, where in 2024 Lisp(s) is the definite better tool vs the dozen of established languages that are used in its place. Yes, technically Lisp is also established but still. Besides that I also think that Li
11.
by mustermannBB 2y ago
Thank you, too for the friendly discussion.
12.
by mustermannBB 2y ago
I don't think neovim is as strong as emacs when it comes to extensibility. It also has no self documenting like emacs. If one is committed to the philosophy of using emacs for everything or almost everything neovim would probably leave
13.
by mustermannBB 2y ago
Again I agree that Emacs is powerful and can be an excellent tool. Never disputed that. But it still, again, to me is clunky. I dislike its defaults, its interface, the ergonomics. Also I have no use for many of its offerings. Could I confi
14.
by mustermannBB 2y ago
To be fair some of these are subjective. People of course should never sell their opinions as objective or facts. Which btw, I don't think the person you responded to did.
15.
by mustermannBB 2y ago
That's why I said IMHO. I tried Emacs in 2023 and 2024 and to me it is still way too clunky, gets in my way all the time and has , what I consider, bad defaults and to me very bad ergonomics. It literally negatively impacts my hands. A
16.
by mustermannBB 2y ago
As long as most Lisps and Schemes rely so heavily on Emacs as part of their tooling, it will never reclaim its status from its heydays. Emacs is just too clunky in 2024. Just IMHO of course. Also Common Lisp, while a great lang with fantast
17.
by mustermannBB 3y ago
"compared to "more accessible" languages and all their hidden gotchas" ---- Yes because APL or array languages in general have absolutely no hidden gotchas ...
18.
by mustermannBB 3y ago
Biggest issue with most Lisps is, IMHO, that you need emacs for a great developer experiences when it comes to tools. And emacs is not for everyone.
19.
by mustermannBB 3y ago
My only issue with Kotlin is Kotlin's over reliance on JetBrain products and being so tightly tied to a company which priority it is to of course sell their IDE. To be fair, one of course use the free community edition but still you ki
20.
by mustermannBB 3y ago
Kotlin is weird inclusion in that list with Java and .NET unless you'd include Android.
21.
by mustermannBB 4y ago
I like OpenBSD, but its very limited virtualization options means I cannot really use it full-time. Also the performance is not that great, but something I could live with.
22.
by mustermannBB 4y ago
As Schemes go Chicken is one of the most practical ones and easiest or straightforward to get into, IMHO! Would love to see it grow more widely adaptation.
23.
by mustermannBB 4y ago
Very nice. Congrats. This looks interesting.
24.
by mustermannBB 4y ago
It is being actively maintained. More important, IMHO, would be if they ( I think it is Chris Hanson these days) would greatly improve some of the documentation. For quite a few things you need to read source code. There is not much for beg
25.
by mustermannBB 4y ago
The issue regarding editors is a real one IMHO. Common Lisp is too tied towards emacs. It can put, people who don't like Emacs, off. And while there are alternatives, but like the author said none of them provide as a complete CL dev e
26.
by mustermannBB 4y ago
Agreed. I never understood this almost unnatural hate towards the mouse by some vim users.
27.
by mustermannBB 5y ago
Regarding employability. Isn't OCaml more prevalent in Europe? France obviously for one but England, too? Also I would assume with knowing OCaml one would also be fairly comfortable with F#, which also should bring some opportunities.
28.
by mustermannBB 5y ago
I like this video. IMHO it is a good example of REPL driven development. Nothing to do with typing things into the REPL. https://youtu.be/C-kF25fWTO8?t=1039
29.
by mustermannBB 5y ago
That is my understanding of REPL driven development, too.
30.
by mustermannBB 5y ago
My problem with KDE has essentially been the same now for years. To me, it feels too fragile.

More ›