Since IPA uses a lot of unicode characters, would it be that much of a problem? IPA, imo, usually has a very specific look to it that wouldn't be confused with "normal" text.
It wouldn't be that much of a problem, but I think there's enough room for confusion, that I think people just wouldn't bother with it. For example, while it would be obvious that /tiθ/ is "teeth", something like /bad/ could be "bad" emphasized, or "bod". It wouldn't be that hard to disambiguate, but it is a little extra strain on the reader.
Most of the time, italics aren't actually all that important though, and could easily be replaced with other linguistic features.
Edit, another thing is that the slashes is actually graphemic notation, not phonetic. There's no reason that you have to use something modeled off the IPA there, it's just common to do so. You could use any alphabet.
This is unrelated to multicore, but Ocaml is a language I want to like. I wanted to learn OCaml with the make a lisp project. That is, until I realized it doesn't have Perl regex built in (yes, I have been spoiled by Python, which has practically everything in the standard library). The best way to get Perl regex was a rarely updated 3rd party library which was missing key features like lookahead and lookbehind.
S expressions are one of the most used serialization formats in OCaml. You can get pretty far relying on the standard parsers and printers. It's what I would do for a lisp in OCaml. Maybe you wanted to DIY as a learning thing? There are other options for parsing including parser combinators or using Menhir/ocamllex which are interesting in their own right.
This isn't really a good answer for someone who wants a regex engine. People use regexes for a lot of things where a full-fledged parser would be overkill, and I'm not sure what serialization has to do with anything.
I completed the make a lisp project in Reason (alternative syntax for OCaml) a few months ago.
I used the PCRE library, which has pretty much all the features you expect, and it is actively maintained. Note: the heavy lifting is done by C libraries.
Were you going to parse S-expressions with regular expressions? I guess that saves you from learning how to write loops and conditionals, and what is substr() called (and what arguments it takes) in this new language, but is not that against the point of learning the new language?
Now, I am a grumpy old fart, but I would suggest to make a one-pass recursive descent lexer+reader. That should be trivial for the MAL lisp. WRiting an ocaml recursive descent parser should be amazingly straightforward, especially since you can just tailcall the different states.
is easier than writing a tokenizer manually (keeping track offsets and looping and stuff), writing that regexp is definitely harder than writing the tokenizer like this:
curr, end = 0, len(s)
while True:
while curr < end and isspace(s[curr]):
curr += 1
if curr >= end:
break
if s[curr:curr + 2] == "~@":
yield s[curr:curr + 2]
curr += 2
elif isspecial(s[curr]): # isspecial(c) matches c against []{}()'`~^@
yield s[curr]
curr += 1
elif isquote(s[curr]): # isquote(c) matches c against "
start = curr
curr += 1
# check this condition out: you can totally support several quotes,
# and accurately match the closing and opening ones. Imagine doing it
# with a regexp: either duplicate it, or use some back-referencing magic
while curr < end and not (s[curr] == s[start] and s[curr-1] != '\\'):
curr += 1
curr += 1 # we want to include the closing quote
yield s[start:curr]
elif s[curr] == ';':
yield s[curr:]
break
else:
start = curr
while curr < end and not (isspace(s[curr]) or isspecial(s[curr]) or isquote(s[curr])):
curr += 1
yield s[start:curr]
Yeah, it's more verbose and somewhat repetitive, but on the other hand, it's way more readable, and debuggable too: with regexps, it's always a mystery which part of it exactly didn't match what you wanted or captured something you didn't want to match. Here, the loop invariants and preconditions are almost immediately obvious.
Does this blog post even contain evidence of the court's leaning? From what I gathered yesterday, the court was hesitant to shake up the software industry. This post seems to just contain the author's hunch/desire?
Also, it'sincredibly condescending, calling people who don't think APIs should be copyrightable "morons" and "stupid".
He is a known shill who was actually paid by Oracle for a while. And disclosed it only after it was uncovered independently. Not exactly what I would call neither an impartial source nor a copyright law expert (he is a software developer and activist, no a lawyer).
Back in 2012, Florian Mueller (the blogger in question) was recognized as a consultant for Oracle in a lower court case that's been leading up to this moment (1).
Even the pro-Google reporters I followed during the arguments yesterday concluded this appeared to be the lean. Both sides claim a ruling for the other side will be catastrophic to the software industry (both are wrong on this, mind you). But the questions seemed largely skeptical of Google's arguments, and one of the most notable claims the Google lawyer made was purely preposterous as a matter of law: That it would've been a lot more expensive to develop their own API and so they shouldn't have had to.
Reporters on Google's side of things seemed to think Goldstein blew conveying their side.
It's pretty wild that the largest discussion site on the internet with untold numbers of young kids on it regularly has NSFW posts hit the top or second page.
It makes me wonder if Reddit will try to push down or altogether ban NSFW content a la Tumblr because of the site's popularity.
I think you may still have to flip a switch in settings saying you're OK with seeing that–but really you don't have to go very far to find content like that anyways, just click on the comments for any post and you'll find something questionable quite quickly.
I unironically miss forums. It was a completely different experience from post/comment based sites because everything was one thread, but the biggest thing I miss is that forums were usually pretty well moderated, smaller, and devoted to one topic.
Reddit is the de facto site for making a community on, but there's something to be said for the focused insular forums of just a few years ago.
The issue with voting based forums is they tend to cater to low quality mass appeal comments.
More often than not an informative comment, while maybe not being downvoted, won't be the top comment. Instead, you'll see really low effort "zingers" which make it to the top. Those are further piled on with a flood of comments trying to one up each other.
So, you end up often needing really strict moderation to curtail this problem.
Chrono ordering suffers the same issue, somewhat, though it doesn't have the pile on problem (not to the same extent).
The Reddit/HN format makes everything time sensitive. If the post falls off the front-page, nobody will even see your comment, the discussion immediately dies. It's completely unfit for longer form discussion over time.
Sometimes you want a forum for discussion, not just a comments section of highlight reel one-liners.
Disagree entirely. Trading chronological sort for whatever drives the most ad impressions and engagements is responsible for the destruction of otherwise decent services.
This boils down to the community you are a part of.
One of the games I like to play has its own forums and they are still the best source of info compared to reddit. Discussions are surprisingly readable, though that may have something to do with the older target audience.
I agree, I can't stand them. That's why I won't use arstechnica comment section. I might look at the first few. I much prefer reddit and hackernews style
But that allows for discussion bubbles to form in this case. Contrarian views are downvoted to oblivion. Not much of an issue in HN, as it is in reddit.
Originally I was more in favor of phpbb style forums and anti likes/favorites/upvotes but I've abandoned that attitude.
I really think it's the same as it ever was. If you want to find quality you need to start with your interests and then find a community from there. Discovering a huge community and being frustrated or upset that it's not catered to your preferences is a mistake. The lower the barrier to entry, the lower the quality of the forum will be.
And it's important to remember barrier to entry isn't just technical knowledge. Barrier to entry could be something as obvious but unspoken as writing style. Even as I'm typing this comment I'm aware that using my "hacker news voice" with all of the attendant style rules that make it fit with the community.
*edit: also I'm sorry to see that you are being downvoted because I get your sentiment
I agree that voting with your wallet doesn't affect large companies. However, for me, not using Amazon is about ethics and choosing less evil companies. Honestly, and I think others would agree, Amazon has had a declining user experience for years now (product names are nonsense SEO soup and the brands are fake/knock off brands) and not using Amazon can be as much practical as ethical.
I'd certainly like to hit Amazon with trust busting regulations, but I have to settle with being "personally responsible" in the meantime.
I would rather just not use clocks than do this. Yes, it would be "better" if we shifted clocks every day, but that's not practical for mechanical clocks.
You may could get away with monthly realignment, but even with that I hate setting my watch even twice a year and I imagine others would too.
I have to constantly look up US imperial amounts. I like that the imperial system is sometimes based on twelves, the problem is where it isn't (volume is based on doubling, inches are successive halving). It's really easy to divide things into halves, quarters, and thirds in imperial, where in the metric system you have to round.
Honestly, a system completely standardized around twelves or sixties would be near optimal.
I forget where I first saw the idea, but I have adopted it as my own: the really sane thing for the French revolutionaries to have done would have been to switch to a duodecimal ('dozenal') counting system, not to base things on ten (which is a really terrible number).
I know you can use emoji as variables in Ruby. Unsure if you can in Python.
Imo it's fine to allow Unicode. Latin will still be the de facto standard character set, but it allows international users to code natively and allows for Easter eggs.
Since PEP 3131 (https://www.python.org/dev/peps/pep-3131/) Python supports unicode in names, but only letters, not emoji. I have occasionally used variable names like ϕ when transcribing a formula in toy code.
The unicode is normalized. That can be used for trickery in rare circumstances. "global" is a keyword, but "𝐠𝐥𝐨𝐛𝐚𝐥" isn't, so you can use that if you absolutely require an attribute called "global".
