3,791 karma · joined August 13, 2016
I don't understand how "only a vague idea" is able to raise millions of dollars in the first place. Can you elaborate or give an example?
Unite is a typical example of something that worked fine and disappear all the same. I haven't find any browser that surpass Opera 12 to this day. All the new "exciting stuff" are no use to me. I don't want to adapt to my browser, I want a browser that adapt to me.
def name := "Hackernews"
# greeting == "Hi Hackernews!"
def greeting := `Hi $name!`
# language == "Lojban"
def `@language is awesome` := "Lojban is awesome"
# one == "", two == "cool"
def `adjacent @one@two patterns` := "adjacent cool patterns"To the second part of your question: as you have undoubtedly noticed, you've never heard of E nor Monte.
Nearly all serious compilers have at least one representation which is not isomorphic for all programs. (It is homomorphic, which is required for the compiler to be correct.) As a consequence, at least some programs will be mangled beyond recognition.
If you convince people that science is true or real not by logic, but by rhetorical tricks, then you are no longer peddling truth; you are blindly proclaiming that science is the only correct epistemology.
> The goal of the Quantum Render project is to take the WebRender compositor in Servo and embed it in Firefox
You're not wrong that Erlang and Scheme are just as much about objects and message-passing as they are about actors.
Kay may or may not agree with me, but I like to require a facet he mentioned in another discussion once: The uniform calling interface. This is the property of objects that you may send any message to any object. If you require this, then Java and C++ disqualify themselves neatly.
"Secure", as a word, does not make things secure. "Container", as a word, also does not make things secure.
Sandboxes come in two flavors: Correct by construction, and exploitable. Which flavor is this system?
What makes this better than NixOS? Than Genode? Than Qubes? Where is the actual security writeup? Where's the explanation of the security model for the system? How would I write code which takes advantage of structural security in the system?
Edit: There's a writeup here: https://github.com/linuxkit/linuxkit/blob/master/docs/securi... And the Mirage design is here: https://github.com/linuxkit/linuxkit/blob/master/projects/mi...
In short, to answer my earlier questions, the sandboxing is undocumented, comparisons to other security-oriented setups are omitted, the limit of structural security is OCaml's type system... This seems like an interesting effort but I am disappointed that it seems more like lip service than an attempt to actually improve on the state of security design.
Second, it's completely reasonable to imagine data-structure-driven improvements to the task of writing source code. Imagine, for example, an AST editor. There are tools like org-mode and paredit which are halfway to true AST editing, and plenty of languages have tooling sufficient to support it, if there were demand. An AST editor would, of course, generalize the lessons here about ropes to pretty-printed ASTs, but there's no innate reason why it couldn't be done.
Third, a meta-comment, to address your comment elsewhere in the thread: "There are, of course, computer science concepts that are very smart. But we don't need these to save us from slow software, because today's slow software problem is just the result of people doing bad things in layer upon layer. We have to stop doing all the bad stuff and dig us out of the hole we're in, just to get back to neutral. Once we are back at neutral, then we can try thinking about some computer science smarty stuff to take us forward."
There are assumptions here about the nature of CS. CS is a science of abstractions. Complaining about layers in CS is complaining about the very nature of CS. Software is slow and insecure and hard to use because the tasks that we demand of software are extremely complex and our human processes for creating code are not sufficiently high-level, powerful, and expressive enough for us to design good systems on the first try.
Whenever somebody says, "I have removed a useless abstraction," they usually forget to also say, "By replacing it with a useful abstraction."
If it fails to terrify you, reread.
I think that it makes coastal city folk uncomfortable to talk about and celebrate KotH because satirizing urban Texan values, beliefs, and practices is self-seen as aggrandizing city-slicker behavior.
This fundamentally doesn't offer much advantage over a .toJSON() instance method and a .fromJSON() class method.
Don't say "security-focused" if you can't handle cyclic object graphs.
Nobody in the last ~20 years has cared about writing Web apps before JS came along. There's basically zero money in it, and it's massively expensive, both in terms of actual development time per feature (easily 10x the cost of working in sane languages with sane runtimes), and also in finding trendy hipsters who don't know algorithms or data structures but took four weeks of coding academy classes a couple years ago. And as for Electron, Electron has existed for over three decades (Project Athena launched in 1983) -- if its massive "Nixon throwing the peace signs before getting on the plane" moment hasn't happened by then, sorry, but it's not going to happen.
But now? People are making all kinds of great new languages, and more often than not, they don't repeat JS's mistakes. People are excited about programming again -- JS is so bad that it's single-handedly revitalizing interest in languages which two of the largest tech companies in the world are behind, yet couldn't make popular.
This is a Big Deal.
(You are being parodied mostly for being a Slack developer, not disclosing it up front, and then trying to convince folks that Electron is good, which makes you sound a lot like a pig farmer trying to sell pigs' feet.)
WP discusses the deadliness, or relative lack thereof, of Japanese concentration camps: "Despite a shortage of healthcare workers, limited access to equipment, and tension between white administrators and Japanese American staff, these hospitals provided much needed medical care in camp. The extreme climates of the remote incarceration sites were hard on infants and elderly inmates. The frequent dust storms of the high desert locations led to increased cases of asthma and coccidioidomycosis, while the swampy, mosquito-infested Arkansas camps exposed residents to malaria, all of which were treated in camp. Almost 6,000 live deliveries were performed in these hospitals, and all mothers received pre- and postnatal care. The WRA recorded 1,862 deaths across the ten camps, with cancer, heart disease, tuberculosis, and vascular disease accounting for the majority."
mlatu = x1 (entity) is a cat of species x2 (taxon) As a noun: lo mlatu — cat.
carvi = x1 (entity) rains or showers to x2 (entity) from x3 (entity) As a noun: lo carvi — rain. lo te carvi — rain cloud.
simxu = x1 (entity group) mutually do x2 (relation between members of x1, contains two places for [ce'u]) As a noun: lo se simxu — done mutually.
cnemu = x1 (entity) rewards x2 (entity) for atypical x3 (property of x2) with x4 (entity, property of x1) As a noun: lo cnemu — rewarder. lo se cnemu — rewardee. lo te cnemu — reason for a reward. lo ve cnemu — reward.
Not all processes can be automated today. Some can only be automated tomorrow. Some can only be automated after some blocking functionality is added. Documentation is how you plan your automation.
"There are two major types of languages, compiled and interpreted."
Well, no. There are two types of language runtimes, compilers and interpreters. (And a technique which can turn interpreters into compilers. [0]) This matters quite a bit if you want your language to not be permanently married to a single compiler; your language design should somewhat accommodate both compiled and interpreted modes as possibilities. This seems obvious in hindsight, but even today, popular languages like Go do not have compilation models which make REPLs easy or even possible.
"I chose C++ because of its performance and large feature set. Also, I actually do enjoy working in C++. If you are writing an interpreted language, it makes a lot of sense to write it in a compiled one (like C, C++ or Swift) because the performance lost in the language of your interpreter and the interpreter that is interpreting your interpreter will compound. If you plan to compile, a slower language (like Python or JavaScript) is more acceptable. Compile time may be bad, but in my opinion that isn’t nearly as big a deal as bad run time."
Okay. This is totally up to the author. It sounds painful, though. JVM legend Cliff Click has said during talks that choosing C/C++ for a VM implementation language is one of the worst decisions that a VM author can make in the modern ecosystem. Memory-unsafety notwithstanding, the amount of effort required to write good C++ is pretty high, and compiler algorithms are complex, so writing a compiler in C++ is very hard.
"In the end, I didn’t see significant benefits of using Flex, at least not enough to justify adding a dependency and complicating the build process. My lexer is only a few hundred lines long, and rarely gives me any trouble. Rolling my own lexer also gives me more flexibility, such as the ability to add an operator to the language without editing multiple files."
On one hand, once your code is correctly factored, an operator will be smeared over several files, presuming that your lexer, parser, and AST class are in at least three distinct modules. On the other hand, hand-written lexers are better at error messages. So it's a tough call and it largely comes down to whether you prefer the pain of writing lex/flex/etc. or writing C++. (This is why a better interpreter language can make all the difference!)
Mr. Bright on parsers, via the author: "Somewhat more controversial, I wouldn’t bother wasting time with lexer or parser generators and other so-called “compiler compilers.” They’re a waste of time. Writing a lexer and parser is a tiny percentage of the job of writing a compiler. Using a generator will take up about as much time as writing one by hand, and it will marry you to the generator (which matters when porting the compiler to a new platform). And generators also have the unfortunate reputation of emitting lousy error messages."
I want parser generators to be good enough. But they largely aren't. These points are all absolutely correct.
"Put simply, the action tree is the AST with context."
These are normally called annotated ASTs. Each node carries an annotation. This can be used for type-checking, two-level syntax, specialization, side-effect-tracking, etc. It's a great technique that really should be publicized in compiler literature. Unfortunately, every interpreter language has different ways to do it. Haskellers will want to use a comonad. Hash-table-rich languages will probably use a hash of AST nodes to annotations.
"It is, but compiling is harder than interpreting."
Efficient compilation is as hard as efficient interpretation. Ignoring the theory of partial evaluation [0], an interpreter usually has to make the same optimizations that a compiler does in order to be speedy. Python and friends, and many other Smalltalk relatives, for example, compile to bytecode. If the bytecode compiler is any good, then the bytecode interpreter will be good too.