111–120 of 212 posts
Earlier quoted context omitted.
What's wrong with Hacker News?
it doesn't respect iOS font size, and you can't alter the zoom to make the text actually bigger. It zooms the entire page rather than just the text, so the text doesn't re-flow. It's pretty much equivalent to just pinching to zoom, when it should be adjusting the font size.
Earlier quoted context omitted.
> Mixtures of the two tend to have syntax problems. My gripe isn’t the syntax, it’s the lack of guarantees/constraints. When I’m working in a language with immutable data structures, I know what to expect. A language like Python with some added functional sugar is much harder for me because I make stupid assumptions. Spent a half hour once chasing down a bug just because I was carelessly assuming list.pop() didn’t al…
You make a good point in general, but I'd be upset if a function called 'pop' didn't mutate anything. That is not the right name to use for returning an element without side effects.
how do you feel about `str.replace`? i'd say that that name implies side-effects too, but everybody's used to the fact that [in python] strings are immutable, so it's no big deal. it's all a matter of expectations and language conventions – e.g. in Haskell, `replace`, `reverse`, `insert` etc. would all be pure functions and no one would think about it twice.
and sure, i'd prefer a "declarative" name if one's available (e.g. `plus` vs `add` on numbers). but if you overdo it you end up naming your functions stuff like `with_inserted` or `with_replaced` and that's just... not up my alley at all (though i'm sure someone likes it)
Earlier quoted context omitted.
it doesn't respect iOS font size, and you can't alter the zoom to make the text actually bigger. It zooms the entire page rather than just the text, so the text doesn't re-flow. It's pretty much equivalent to just pinching to zoom, when it should be adjusting the font size.
Why can firefox on the desktop resize the font on HN and reflow the content, but iOS cannot?
I want to implement a toy programming language, but I have questions regarding the following in that article: > Context free grammars. What this really means is the code should be parseable without having to look things up in a symbol table. C++ is famously not a context free grammar. A context free grammar, besides making things a lot simpler, means that IDEs can do syntax highlighting without integrating in most of…
Context-free has nothing to do with symbol tables, it just means that in the grammar, the left-hand side of a production rule can only have a single non-terminal symbol, which can always be replaced by the expression on the right-hand side, without ambiguity. Language features are an orthogonal issue--you can implement any language feature with a CFG, but you just can't reuse the same keyword or operator to have diff…
"""
The line
TimeKeeper time_keeper(Timer());
a variable definition [...]
a function declaration [...]
These things you can only resolve by having the symbol tables around and checking. The parser alone can't tell.
A language could avoid this i.e. by requiring specific keywords or having more distinct syntax.
Humans (programmers) however often can deal with ambiguity, we have it in humannlanaguage as well and context on most cases helps and I argue those aren't practical problems. (While that's only opinion)
Lately I've been wondering if I should reconsider, though, and have had a bunch of ideas that blur the lines of what should be considered in-scope for a programming language. Things like:
1. Universal constructs for serial & parallel execution, but with user-defined semantics for where the code should execute. So for example, at low-scale you'd execute in a loop on the CPU. At mid-scale it'd run on the GPU. At high-scale you could transparently distribute across thousands of GPU boxes.
2. Profiling and execution statistics built into the language. Write your code, run it on representative data, and instantly get statistics on how many times each function is called, what the average size of data structures is, how much memory is used, etc. Profilers do this, but often not at a granularity that's particularly useful (ever tried to find out how many Strings are created within a particular dynamic call-tree?), and most new languages overlook implementing a profiler, leaving it to third-party vendors. This is a shame, because a standardized programmatic API to a profiler could be a very effective compiler tool, leading to...
3. A way of defining transformations between data representations, benchmarking the cost of those transformations, and then having the compiler automatically decide whether it's worth bulk-converting data based on typical profiler results. The motivating example for this is the AoS-SoA transformation, but they also feature in common system design questions like "Do you unpack all of the fields of this wire protocol, or lazily construct an object only when necessary?" or "Should you zip your data before sending it in an RPC?" or "Do you do this work at indexing or serving time?"
4. The ability to dump intermediate data from any function call site to disk, and then restart program execution from there without re-running the whole program. Handy when iterating on a complex algorithm.
5. Drill-down data visualizations for large collections. If you've ever tried to find the logic bug in a 500,000 element array using a standard IDE debugger, you'll know about this pain point.
6. Built-in support for machine-learning. In particular, many ML applications need extensive preprocessing, and you need to preprocess the data in exactly the same way for training and serving. Wouldn't it be neat if you could write your traditional algorithms, dump out your signals at the particular call-site of the classifier, and then have the development environment automatically send it to Mechanical Turk or Craigslist for labeling? Then have the system return the labeled data in a format easily suited for your ML framework of choice, do your data analysis & training, and import the finished model back into the call site of the language.
7. GPU-native, with language constructs that lead to efficient GPU code. This is becoming increasingly important not just for execution speed, but for developer velocity, because devs in data-intensive areas can waste a significant amount of time waiting for their program to run.
I want to implement a toy programming language, but I have questions regarding the following in that article: > Context free grammars. What this really means is the code should be parseable without having to look things up in a symbol table. C++ is famously not a context free grammar. A context free grammar, besides making things a lot simpler, means that IDEs can do syntax highlighting without integrating in most of…
This point in the article is pretty weird (the rest is good). I don't think IDEs do a lot of parsing to do syntax highlighting, isn't it all just regex matching to identify the types of tokens? I'd be interested in real-world examples of IDEs doing something more complex to achieve syntax highlighting. And conversely, examples of imperfect syntax highlighting of C++ due to the undecidability of its input language. I…
Variable renaming respecting scope, function renaming that updates the name at the call sights but ignoring overloads, function extraction... and so on. You may not use it or indeed use eclipse at all.
I can't tell you about the details, clearly something going on beyond syntax highlighting via keyword regex matching. With a beefy enough box it all works well enough.
You might be doing this as a learning exercise, in which case it doesn't need to be particularly innovative, and writing another Lisp or Forth implementation is fine. In fact, I'd recommend beginning along those lines, followed by developing several different new languages, probably domain-specific ones. Your first attempts probably won't be worth keeping. (I haven't kept the object oriented Prolog I wrote about 25 y…
Don't know enough about it but feel missing Simula from your list
Earlier quoted context omitted.
Ruby has a nice convention where impure functions like those have a "!" appended to the name. For example String#gsub takes immutable string arguments and returns a new string, but String#gsub! operates on a String instance and mutates it. I guess if you write a new programming language, it would be nice to establish that convention early on, when it's still possible to be done.
The problem with Ruby’s approach, if I recall correctly (been 10 years) is that it’s inconsistent.
Earlier quoted context omitted.
Sure. You can see it in action at http://darklang.com/launch/demo-video (also, we've gone through our waiting list, so we're pretty much adding new folks who sign up immediately, if you want to try it out). The main idea is that you when you make a change (let's say, you type a key in the editor), that change happens directly on the AST (the internal set of objects that represent the program). So for example, if you'…
That sounds…potentially confusing? Correct me if I'm wrong, but it just continues to run the last version of the program without errors, but it won't tell you if the current version is syntactically invalid?