steinuil

I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this.

That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.

Your complaints have little to do with wasm; as the post says it has no direct access to the DOM.

wasm is only supposed to speed up heavy computations like those needed to decode and rasterize the PDF, modifying the page is still done through javascript.

It's the version of vi that ships with the BSDs.

No, I just think it's a messy way to address the problem.

Actually, for loops in languages like Ruby and OCaml are just syntactic sugar for map.

Also, why would you prefer an imperative construct over different kinds of folds?

Well, clearly in a language that doesn't make a distinction between functions that have side effects and functions that don't you'll just have to pinky swear you won't put any in your functions, and maybe try to wrap the side effects the built-in functions do have (like errno in C) with your own functions.

But that's not the point; a functional style can be achieved in any language as long as it has functions.

Like the article said, "functional programming" doesn't mean using maps and folds. Functional programming is meant to make you reason about state by always handling it very explicitly e.g. by using functions that take a state and produce a new one, so that your program is constructed by piping the result of a function into another's input, instead of implicitly.

I was interested in Gobo a few years ago, but I was a bit turned off by learning that it achieves this mostly by using a lot of symlinks.

I've used Elm for a while and I don't really see what's the problem about JSON decoders/encoders. Sure, they're verbose and annoying to write if you have a particularly intricate JSON structure, but I don't really see a better alternative for decoding and encoding JSON in a type-safe way, and with Elm's constraints on ease of learning.

More freedom on type-level programming would help, but that would certainly complicate the type system, and the only language I know that lets you fold over arbitrary record types is Ur/Web, which has a richer type system than even Haskell, and I don't see Elm adding things to its type system (other than type classes, hopefully), given that other interesting features were already removed because very few people used them.

Yep, there is very little discussion over taking the language in other directions, because ultimately Evan supposedly knows best. It's sad to see such a nice project being bogged down by such a mentality, but Evan really brought this upon himself.

I think the advantages of depending on a single person only come out when that person has a clear vision of where they want to bring the project.

I feels like Evan doesn't know what to do with the more advanced features that Elm, in my opinion, desperately needs, and I've been pretty unhappy with how he's taken a policy of removing stuff because nobody uses it.

Actually, Rake has both. You can define file targets using "file", but I found that for smaller projects it just becomes a more verbose make.

I don't think there can be an absolute measure of how good of a programmer one is; it is a function of how well acquainted one is with the problem at hand.

A problem is not only defined by stuff like the core routines of the program, but also everything surrounding it, like the structure of the code and of the program as a whole, the environment the program is supposed to be running in, and how to collaborate or manage the other people who are working on the program. Though at this point it's probably better to use a broader term like "software engineer".

A programmer who has enough experience across the whole stack for a certain problem is going to be able to deliver good, readable and efficient code in a timely fashion.

In Racket and other Schemes parens and square brackets are interchangeable. The Racket style guide suggests to use square brackets in let- or cond-like expression, or generally any expression with a list of lists of fixed length that are not supposed to be evaluated. The expression you posted would become like this:

    (do ([i 1 (+ i 1)])
        ((> i 100))
      (display
        (cond [(= 0 (modulo i 15)) "FizzBuzz"]
              [(= 0 (modulo i 3))  "Fizz"]
              [(= 0 (modulo i 5))  "Buzz"]
              [else                i]))
      (newline))

I personally think this helps a lot with the problem of parsing s-expressions visually.

There is, but it has more to do with the people joining later and not understanding/respecting the unwritten laws of the community.

Here's an interesting essay about this effect: http://shirky.com/writings/group_enemy.html

#3 is basically how Typing of the Dead works, and when you reach high WPM it is indeed faster than using a mouse.

This reminds me a lot of the posts by burnt out open source project maintainers, like the one about turning off github issues that was on the front page just recently, or one from a while ago about ignoring most github notifications and marking old repos as unmaintained.

I think the two things Elm lacks the most right now are some form of polymorphism and some way to make parts of an Elm application manage their local state.

At the moment there's only an internal API for the latter, and it's pretty ugly. I think what would be good for Elm would be to spin up a few separate Elm processes and provide an easy interface to make them communicate, sort of like in Erlang. You can do this using ports and binding them together with js right now, but it's kind of ugly.

Even C can do hot swapping using shared libraries, and it has none of those features.

This just looks like bad UI to me. On my desktop browser I often press End to get somewhere near the end of the page, here if you do that it just goes back up.

If I accidentally scroll to the end while reading something I can't scroll back up, I'll have to scroll down to the end and hope I don't scroll too far and trigger the loop again.

A bit off-topic, but I'm italian and despite my best efforts to use english as system language on my Windows installation, I still catch some programs using italian.

Where do they even get it from? Date and currency formatting settings? Timezone? I'm baffled.

The problems I have are often related to how to use a certain library or a certain function in a programming language I don't know that well, in which case I often try to search for similar code on github to see examples, or look at the library code.

For stuff like "are there optional parameters in .len()?", I always keep a tab or two on both the documentation of the language and the library I'm using at the moment. I really like how some languages come with specific tools for documentation (ri in Ruby, the `doc` function in Clojure) and I try to use them as much as I can when available.

I've been using mobile.twitter.com on my desktop browser for a while in place of the main website, and I find it much better and more pleasant to use.

And? If FreeBSD had a more restrictive license, the developers of those products would have simply chosen another similar project, or used proprietary software.

Wayland works pretty well now, it's just lacking software support. And even that's not much of a problem, because you can run X clients inside it with XWayland.

It is not strictly "experimental software" at this point.

Also, Fedora is the "bleeding edge" distribution of Red Hat and is purposefully usen as testing bed for new features, like in this case Wayland.

So if you're using Fedora and don't like Wayland, systemd and other such "experimental software", maybe you should stop using Fedora.

(That's not to say I like Red Hat or what it is doing to the Linux community by forcefully pushing whatever they want to be the default on every Linux distro out there.)

It's a bit barebones, but it's very easy to use. You can also generate standalone executables effortlessly.

I'm writing a shell that does this; right now I'm working on the language itself (a somewhat functional language with basic types and records) and its parser (the syntax is like a terser OCaml mixed with Ruby, designed to be quick to write), but eventually it'll reimplement most unix programs so that their output is actually a type it recognizes, and it'll have something like a FCI (Foreign Command Interface) that would let you easily parse the ouput of commands it doesn't implement.

It's not uploaded anywhere yet (and there's not much to look at right now, just an unfinished parser and the beginning of an interpreter), but when I have time to work on it and put it in a somewhat functional state I'll post it on here too.

I'm not saying they are, I don't think I've used the language enough to be able to tell what's pythonic and what's not. It's just that I think the language support could be better: why defining a function and calling it right after? That's what lambdas are for.

I had to work with Python a few times in the past year and I really have to agree. The lack of proper lambdas, closures, its reliance on mutable data structures and imperative idioms, and the useless distinction between statements and expressions makes it feel like somebody was trying to write a modern language but for some reason stopped halfway.

For example: you can't assign the result of an "if" statement. Why? Because it's a SyntaxError, no real reason. There is even an "ifExp" in the language grammar, but that's only for inline ifs.

You can't have statements in lambdas, and map and filter are "unpythonic". Yet everybody feels like list comprehensions are the best thing after sliced bread, despite being the same thing.

Closures are also clunky: you can define another named function inside a function and call it afterwards, and you can use functools.partials from the stdlib, but I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method.

Ultimately, to me it feels like this all hurts the composability of the idioms of the language. List comprehensions can be nested, but they feel clunky and they're in a syntactical wall garden. You can compose expressions, but not statements.

Yes, that was it! Thanks for finding it.