61–70 of 179 posts
Earlier quoted context omitted.
UI is weird. Left/right goes between main topics, up/down goes through the slides on that topic. So if you just go right, right, right, you're only seeing the headings.
Over here in Firefox 52.0a1, something is cut off the margin of the slides.. all of them. I can briefly see the cut-off part when flipping to the next slide (vertically or horizontally).
I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Making a DSL lets me construct a language to express my program that meshes with the way I think. Unfortunately, we all think differently, and what is intuitive and friendly for me is hostile and awkward for others. While reading someone else's program that…
It makes the up-front design more difficult—you can't just muddle through a design without thinking deeply about it—but pays off in the long run.
If you have nice semantics, I think the advantages of building a DSL (mostly greater expressiveness and flexibility) vastly outweigh any confusion people might have about the different syntax. If the semantics are genuinely simple, learning how the syntax maps to then should not be difficult.
And with unclear semantics, even a non-DSL library is going to be hard to use and understand.
I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Making a DSL lets me construct a language to express my program that meshes with the way I think. Unfortunately, we all think differently, and what is intuitive and friendly for me is hostile and awkward for others. While reading someone else's program that…
Earlier quoted context omitted.
Newcomers are always confused by the distinction, this doesn't help at all to put them in the same big bag. This classification is not wrong, but mostly useless when you see how the different "dialects" evolved (they are grown-up languages, nowadays). > C is a language, not a family of languages that includes Rust and Go. But Rust and Go are constantly compared to C. We always talk about C-like languages. Maybe I sho…
> Newcomers are always confused by the distinction, this doesn't help at all to put them in the same big bag. This classification is not wrong, but mostly useless when you see how the different "dialects" evolved (they are grown-up languages, nowadays). Sadly, language is determined by usage, which only incidentally correlates to usefulness. And critically, there's a feedback loop here: a word is only useful as it's…
The people who create Common Lisp didn't think that is was coextensive with "Lisp", so I'm not sure why that would have become _more_ true in the last 30 years.
Earlier quoted context omitted.
Cider's integration of Clojure into Emacs is reasonably comparable to what traditional SLIME integration for Common Lisp is like, as a user experience. Likewise, Geiser is a sort-of capable mode for most of the other more prominent Schemes; though it is not quite as elegant or polished as Cider.
geiser is quite nice. I used it a couple of years ago with racket to work through the first three chapters of SICP, including the part that involves drawing pictures https://i.imgur.com/fwCUUZI.png
I went to school at UC Berkeley. My first language was Scheme. Then Elisp. CLOS was in the first few too. I really didn't learn C or C++ until second semester.
A few months ago I had to pick up enough Scala to figure out what some code did in a project and I wasn't really happy with the language. I realize it is multi-paradigm, but the functional part just seems a little bolted on at times. The notation was clunky. Maybe it is because I prefer Lisp-ish and APL-ish languages. And the Scala docs aren't very friendly. I actually find it easier to write imperative code in Scala than functional code.
Clojure seems nice, but lacks a lot of things that you kind of want in a LISP (proper tail rec). Racket has very little market pen.
Maybe I'm just picky, but I don't see anything I really want to put time into.
Earlier quoted context omitted.
Restarts, call/cc, reasonable error reporting, reasonable error reporting , real tail-call elimination.
I thought the general consensus on call/cc now is that although it's very powerful in principle it's not such a great abstraction in practice. It's difficult to implement efficiently and abstractions created using it tend to be very brittle. See e.g.: http://okmij.org/ftp/continuations/against-callcc.html
http://okmij.org/ftp/continuations/undelimited.html#delim-vs...
Earlier quoted context omitted.
Are there (m)any advantages to doing this? I've seen a number of shell-interop modules for various languages but they all appear to add an extra layer that reduces portability or ease of maintenance.
> Are there (m)any advantages to doing this? [trigger warning: cynicism distilled from 15+ years of bitter tears] More fun and better job security for the current maintainer. The former because one hacks away in the preferred language, the latter because one cannot be replaced easily by some unix geek unless s/he happens to speak the same language fluently. One can chose from various implementations in various langua…
Earlier quoted context omitted.
> bog-standard "foo | bar | baz | ..." Surely if you're doing that then shell is the way to go? What cases are there for performing that sort of piping inside a "real software engineering" program? (And if you're doing it inside a single program, why aren't you making several independent programs that pipe to each other?)
When there are a few pipes, surrounded by hundreds of lines of logic, parsing, pretty-printing, error reporting, etc. then it makes sense to use a non-shell language. The problem is that invoking subprocesses can be quite verbose. If you do the naive thing and pass strings in/out of each step, it increases verbosity, gives you temporary variables to abstract away and can eat up a lot of memory with temporary data. If…
Which is why SCSH is kickass.