I switched to the Dvorak keyboard layout sometime in the early 00s.
I've never owned a keyboard that was actually physically labelled for Dvorak, so I _cannot_ type if I can see my fingers. The lies printed on the keycaps throw me off every time. :)
Most modern C++ code that I've seen restricts code to declaring a single variable per statement.
It's not really a big deal because things are also always introduced at the latest possible position. Each is also typically given an initializer. I'd consider it suspicious if I were to see C++ that declared 3 uninitialized pointers back to back like this.
And then you get to the codebases where the authors have chosen to embrace auto and type inference... :)
Hello! I am the lead developer of the Luau type checker.
I actually hadn't heard of Teal! I don't think it existed when we started.
Judging from the Teal documentation, I'd venture that it looks pretty similar to Luau in everyday use.
If I were to guess, I'd venture that the biggest differences are probably the kind of type inference we do (Luau's inference engine draws inspiration in equal parts from OCaml and TypeScript), a bunch of Roblox-specific features, and that our inference engine is all C++ for performance.
I've been meaning to try out roblox for a while and lately I've been getting pretty hyped about teal (for context, the guy behind it is the creator of luarocks and htop, among others) so I might see the differences up close sooner rather than later :D
EDIT: (unrelated) Already not looking forward to people asking "Lua" questions about typing and constantly having to explain that Lua is not just a roblox thing xD
I don't think many people would enjoy that at all.
The appeal of games like Dark Souls (and Slay the Spire!) at high difficulties arises from the knowledge that you _will_ win if you are clever and observant enough.
It's the learning process that keeps players coming back to these games, not the Game Over screen.
I did a bunch of professional Haskell work in a prior life[1]. Most of its 'secret weapon' status springs from the way Haskell lets you control side effects.
We had a fantastic unit testing harness[2]. With effect tracking, you can arrange for your harness to put precise fences around nondeterministic code. You don't need to rely on experience and discipline to ensure that tests are reliable or fast. The type system does it for you.
Effect tracking also makes concurrent code easier to write. You have a great deal of control over how and when threads can be created, and what kinds of logic is permitted on those threads.
GHC's IO manager offers green threads and async IO, so rather than a select loop, you just fork threads and perform "blocking" IO calls. You get about the same efficiency as a select loop this way.
Lastly, something we learned to appreciate over the years is that Haskell is easier to refactor. When you combine the rigid type system, effect tracking system, and ease of writing unit tests, it becomes very easy to refactor old Haskell. It doesn't really matter how bad the old code was or whether the original author is around to help you at all.
If you intend for your product to evolve continuously forever, this is truly a secret weapon.
Of all the things I like in haskell (having only used it a as a hobbyist), refactoring tops the list. It's a lot less scary to refactor when the compiler tells you so much about which parts you missed.
If you are going to expect me to run your software in an always-on manner, I would greatly appreciate a native application.
I frequently do light computing on a Surface Go. It's a delightful little device and I love it, but it is not powerful enough that I can leave gmail, Slack, and Discord open all the time.
I don't have enough RAM to run another web application but I could very easily afford a native app or two.
I have an old ThinkPad X200s that I turn on from time to time. I keep a fedora installed and updated just in case, and since I'm there, i also sync my nextcloud stuff.
E-mails using claws-mail are not a problem. It generally runs fast enough until I open firefox and web stuff in general.
Claws Mail on an old Atom is a lot faster than webmail on pretty much anything else. This probably illustrates best the difference between the two approaches.
Indeed, I asked on another HN thread, why do you developers need so much RAM, and I got lots of good answers. But it occurs to me that a few lightweight, quick-starting apps will help me stave off the day when I have to get a new PC because my old one ran out of juice.
I'm not sure that's enough of a reason to develop a commercial app, because tightwads like me also like our stuff to be free.
The author seems to be implying that we have a hard choice ahead of us with no middleground: We can either accept object oriented programming, or we can turn to pure FP.
The OCaml community presents a pretty compelling third option:
OCaml is billed as a 'functional language,' but it doesn't do anything to prevent you from performing mutations or executing side effects anywhere you want. It even has builtin syntax for "for" and "while" loops.
Interestingly, OCaml does afford classes and objects but hardly anyone seems to use them. It's not that OCaml objects are weird or difficult or bad in some way. People just choose to write records and functions. Some of those records have functions in them. Some of the functions mutate state.
In the OCaml world, at least, pretending OOP never happened seems to have worked out just fine.
> "The author seems to be implying that we have a hard choice ahead of us with no middleground: We can either accept object oriented programming, or we can turn to pure FP."
I disagree. I dont think that is what the author was saying at all, not even a little bit:
"100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work. But if the slider between functional purity and 1980s BASIC-style imperative messiness is kicked down a few notches — say to 85% — then it really does work. ... It’s possible, and a good idea, to develop large parts of a system in purely functional code. But someone has to write the messy parts that interact with the outside world."
And over 99% of OCaml projects don't use objects at all. You would be hard pressed to find an OCaml developer who would care if objects were just removed from the language entirely.
There isn't really a middle-ground (with regard to side-effects) despite people arguing for or against it - much like those memes where someone declares that they're not 'for' or 'against' abortion.
Either I can rely on the fact that `foo() == foo()`, or I can't.
Either I can rely on the fact that `map f . map g == map (f . g)`, or I can't.
The properties you describe regarding pure functions are correct and useful, but those ideas miss the point:
Neither OO nor pure FP are required to build high-quality software!
OCaml developers have been living in this world for decades now and they seem to get by just fine. Further, they do this purely by choice! Their language has had OO syntax for decades and they are happy ignoring it!
Nondeterminism is every place where information can enter your program from the outside world.
It's random numbers, the system clock, data off the internet, and input events from the user.
What it sounds like is that Mozilla has come up with a debugging environment that bottles all that nondeterminism up into a neat little package so that it can replay a specific run of your program any time you want.
For what it's worth, I get the feeling that the reason TypeScript is growing so much complexity is not because the language designers expect you personally to use it all.
It's there primarily so that your development environment can give you accurate feedback when you're using your favourite JS libraries.
Exactly. The <title> of typescriptlang.org is "javascript that scales". All those features in TypeScript exists to express common js idioms in terms of a static type system, which in turn enables stuff that makes programming in the large easier.
I've never owned a keyboard that was actually physically labelled for Dvorak, so I _cannot_ type if I can see my fingers. The lies printed on the keycaps throw me off every time. :)