HN user
https://maxhallinan.com
Ohio, Kentucky's neighbor to the north, also has a rich archaeological record. The Ohio Archaeological Society's journal is archived here: https://kb.osu.edu/handle/1811/55832 Fascinating read for anyone interested in this topic.
You might be interested in StarLogo. [1] It's a Logo dialect designed for simulating decentralized systems and emergent behavior.
How do you find processes that can be automated? I've often thought that there must be a ton of this stuff in various industries where programmers aren't typically embedded.
What's the link?
I like statically typed functional languages but I'm interested in understanding why people dislike them.
Location: Munich, Germany
Remote: Yes (remote only)
Willing to relocate: n/a
Technologies: JavaScript, TypeScript, Elm, Haskell
Email: maxhallinan <at> gmail.com
Thanks!
Where does this community of hobbyist language designers gather online?
How does the Aesthetic Usability Effect account for the success of websites like Amazon, Wikipedia, Craigslist, Hacker News, classic Reddit, and LinkedIn, to name a few? There seems to be no correlation between aesthetic quality and use of these sites. I'm not sure what that indicates about the "usability" of these sites. If the goal is to maximize the number of users, it would seem that there is some evidence that a sense of usability determined by aesthetic quality is not that important.
Computer science is a specific treatment of these topics that is based in formalism. Compare John McCarthy's "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I" and Paul Graham's "The Roots of Lisp". These papers cover exactly the same material. But only the first is computer science because it uses a formal language to express the ideas.
Ok, I think I read more into your first comment than you actually said.
many routes are just not focusing on the higher level design skills that I think are needed to make good libraries/frameworks/DSL's.
I have observed that too. But I don't think this is about who is and isn't a computer scientist, whether self-taught or formally trained. I think it's more a change in the way people relate to programming languages. Perhaps programming languages were commonly assumed to be principally an academic topic. Perhaps it's not that more people are becoming computer scientists but that more people are finding non-academic ways to relate to programming language design. I think what Butterick did was to build the tool he needed to do a job (write a book). So language design becomes just like any other form of hacking.
Why wouldn't the author qualify as a self taught computer scientist though?
Butterick himself is adamant that he is a lay person. He compares himself to a "squirrel in a ferrari": https://www.youtube.com/watch?v=IMz09jYOgoc And that's his point in that talk - Racket makes it possible for even the lay person to build the language they need.
A developer who knows how to code and hack may not have the skill/design knowledge to properly create a language/DSL, perhaps making a monster in the process. A well trained computer scientist (academic, self taught, doesn't matter) should have those tools and more importantly the design know how.
The author of Beautiful Racket, Matthew Butterick, is a lawyer and a typographer. He is not a computer scientist. And yet, he designed a DSL called Pollen for creating web-based books. Pollen has been quite successful within the Racket community.
My understanding is that Racket is predicated on the idea that people like Matthew, as much as people like your computer scientists, are the best authors of DSLs. They are the ones who understand the domains they're working in. If the division you predict ever does exist, it is because the tools have failed to make people who are not computer scientists capable of creating the DSLs they need to solve their problems. It's not because languages are inherently better designed by experts in the domain of programming languages.
You're right: there isn't much substance in my comment. I just meant to qualify the parent comment by saying that not everyone found this to be a "Best talk of 2018". A lot of good arguments for both sides were made in other places and it felt a bit obnoxious to reopen the argument here, where it's off topic. I should have simply stated that this is a controversial talk instead of adding my two cents.
Here's my understanding of one of your points: required fields in a data serialization format place an onerous burden on consumers. So in proto3, every field is optional, and this permits each consumer to define whats required for its own context.
Unfortunately, I can't find any connection between the dilemma at Google and the suitability of the Maybe type. You say this:
The issue is that the shape/schema of data is an idea that can be reused across multiple contexts, while optional/required is context-specific. They are two separate things conflated by type systems when you use constructs like Maybe.
I agree - the value of a field might be a hard dependency for one consumer and irrelevant to a second consumer. But Maybe has nothing to do with this. If the next version of protobuf adds a Maybe type, it would not obligate consumers to require fields that they treat as optional. It would just be another way to encode the optionality, not optionality as a dependency but optionality of existence. A required input could still be encoded as a Maybe because the system can't guarantee it's existence. So Maybe is simply an encoding for a value that isn't guaranteed to exist. And that's exactly the scenario you described in proto3 - now every field could be encoded as a Maybe.
A second point that stuck out to me:
I didn’t understand “the map is not the territory” until I had been programming for awhile. Type systems are a map of runtime behavior. They are useful up to that point. Runtime behavior is the territory; it’s how you make something happen in the world, and it’s what you ultimately care about. A lot of the arguments I see below in this thread seemingly forget that.
Your worldview here is very different from my own, and perhaps while this difference exists, there won't be much mutual understanding. I don't find any relationship between types and anything I understand as "runtime behavior". Types are logical propositions. The relationship between programs and types is that programs are proofs of those propositions. Runtime does not enter into the picture. That's why constraint solvers work without running the program.
I thought this was one of the notably bad talks this year. The whole premise that a function of Maybe a should be a function of a without an API change is neither intuitive to me nor really justified by Hickey. Different things are different. It's sad to see someone build such a wall around himself when faced by something (type theory) that he doesn't understand.
Brainfuck certainly is small. I think it might also be an example of what I had in mind. Brainfuck could be a little language for the idea of a Turing machine. Perhaps by writing Brainfuck programs, one better understands the mechanics of the Turing machine.
Thanks for mentioning Racket. I'm aware of the language but didn't know it know it was designed specifically for "language-oriented programming".
You're right, these languages have a slightly different aim but it's exactly the same motivation.
Thanks for sharing this!
There's a multi-writer feature for Dat under work.
Did you take psychedelics in a clinical setting?
I took Mindstorms to be more about a necessity-driven approach to learning. I would guess you're right: not everyone will find Logo interesting. But I think that everyone has something they want to do and are currently incapable of doing. I thought that Papert was using Logo to show how a general education can occur in the process of acquiring that desired capability. In the context of Mindstorms, this was always a new capability as a Logo programmer, e.g. being able to draw flowers. But I thought the more fundamental point was that people will acquire generaly applicable knowledge through the pursuit of some specific and sometimes (seemingly) trivial skill. This principle isn't contingent on using Logo for anything.
Is the "US only" constraint for tax purposes or about timezones? Can American citizens in Europe apply?
The compiler was telling me that there was no field foo on props but there clearly was.
You make a good point. I don't mean that TypeScript yields no benefit. But if I can't trust the compiler 99.99% of the time, then I find that I'm double-checking my work _and_ the compiler's work. It's not clear to me that the benefit outweighs this uncertainty. When you say that your system is "sounder", you don't really know whether that's true if the type system is unreliable.
Thanks for the tip! I'm gonna try this on Monday.
To be clear: I'm not complaining about these third party types. I really appreciate that people took the time to write and share these. My gratefulness is definitely not contingent on perfection. I fully expect human work to be imperfect. Type systems exist to guard against this imperfection. A type system in which type annotations are maintained separately from the implementations, and are routinely debugged is highly suspect.
Passing props through a higher-order component using JSX's spread operator instead of the attribute syntax, e.g. `{...{...props, foo, }}` and accessing that prop in the wrapped component. I found it was possible with the attribute syntax. More examples can be found in the issues for `@types/ramda`. In some cases, the types are incorrect. In other cases, TypeScript's type inference is too weak.
in various cases the types are wrong and the compiler doesn’t care
It's disturbing how often I encounter this in TypeScript. Or its inverse: the types are correct and the compiler is wrong. Or a third common problem: the types for a library are incorrect. The unsoundness of TypeScript is not merely theoretical. The compiler is frequently just wrong. For that reason, I am mystified by the amount of enthusiasm for TypeScript that I encounter online.
I tried out Kubernetes (managed with kops) for a personal project. I had a single websocket endpoint. I wanted to terminate SSL at the load balancer. Found this to be extremely complicated and the troubleshooting resulted in a ~$100 AWS bill.
To add to this, be aware that once the probation period is over, you have to give 3 months notice when you terminate your employment. Once you actually have a job in Germany, finding a new job is a much bigger piece of long-term planning than the U.S.
Andre's talk "The Past, Present, and Future of Cycle.js" [1] describes how Cycle was grown by the community through discussion and experimentation.