jfe

I compute the resized windows and columns on mouseup to imitate how the Acme text editor does resizing, but the event handler which computes the resize could very well be called on mousemove if preferred. Maybe it'd be worth adding that as a customization in the library interface.

Thanks. I'm not sure how many people have three mouse buttons but it wouldn't hurt to make the buttons respond to middle-clicks the same way they do to left-clicks.

Thanks. Which browser are you using? I noticed this issue in Firefox but thought I fixed it. I've tested it using the latest versions of Chrome and Firefox and it seemed to work.

Omnino does not implement the "right-click to load" functionality of Acme, as it's meant to be a general-purpose library. However, I have implemented this functionality on my personal website and plan to open-source this code as a separate library soon. You can see it here: https://spelunca.xyz/

what is with programmers and needing to defend a combination of syntax, semantics, and runtime? C++ is a programming language with advantages and disadvantages. end of story.

would you also criticize newton's principia mathematica because he expressed the concept of infinitesimals using geometry instead of using liebniz's or lagrange's arguably clearer notations?

K&R was written in a different time, where computing had stricter (but not really different) constraints, but it's still arguably the clearest expositions of the language around.

considering computing hasn't changed that much since K&R was written, it's unlikely your idea of good code differs much from what was done 40 years ago. for example, functional programming, which is the popular dogma today, was invented around that time.

take the good (it's not hard to find in a book like K&R), discard the (perceived) bad, and move on with your life.

hand-roll it. a 3-minute programming task doesn't warrant pulling in a graph of dependencies a la leftpad.

looks like the fox is guarding the hen-house.

i wonder if the size could be reduced by replacing the yacc code with a hand-written parser.

I used to think that being a software engineer meant you were intelligent, and worked hard to earn the title, but after working in the industry for 6 years, I decided that, large-scale software project management problems aside, industrial computing just isn't that hard relative to math and the sciences.

Once you know a dozen languages and understand the running themes of computing, it's all sort of old-hat. Ironically, as the field has been flooded with young, inexperienced devs to satisfy market demand, the titles of "software developer" or "nerd" have become social badges to indicate one's intelligence and cutting-edge-ness. We use 50-year-old operating systems and call ourselves innovators.

Maybe, like Groucho Marx, I just don't want to belong to any club that would accept me as a member, but I think that if you're looking to level-up intellectually, studying math and science, but especially math, is the way to do it. I was never good at math, but I've spent the past year teaching myself calculus and the struggle has been well worth the expansion in my world-view.

iirc dennis ritchie was an applied mathematician.

every framework we use -- library, language, runtime, operating system, hardware -- makes decisions that constrain what we can express.

languages like haskell, lisp, or ruby may make it easy to create new control structures that blend well with the existing syntax, but new control structures don't help if it's still annoying to write, say, very long lines of free-form text -- a problem that xml handles more gracefully than lisp. syntax makes a difference.

i think it's unlikely we'll win a several-orders-of-magnitude decrease in complexity by confining ourselves to the syntax decisions of one language.

i feel like each "new" general-purpose language project is just nipping at the boot-heels of the much bigger problem of constructing large-scale systems that can be fully understood by a few (2-3) people.

VPRI's research has shown that one important method for constructing large-scale systems that can be understood by small teams is to have a pipeline of problem-specific languages that express major portions of the system. they were able to reduce LOC for a typical OS with networking and graphics by 3 or 4 orders of magnitude.

general-purpose languages can't compete with DSLs in terms of expression, and yet we keep inventing them. i think our lack of imagination is starting to show. compilation and language design will need to become much more common-place if we expect to continue scaling up.

a tower of babel in computing is healthy, no matter how much employers want us to be easily-replaceable cogs in an IT machine.

I'm compiling a computing research publication/invention "greatest hits" to help myself and others learn what's already been done, and avoid, as Alan Kay would say, "reinventing the flat tire." Your suggestions for noteworthy publications or inventions are welcome.

so easy, any 10 year old with 30 years' experience can do it.

true tolerance tolerates the intolerant.

Do a substantial number of IRC users actually care that the current version of IRC lacks the features that IRCv3 proposes, or are we just modernizing because we want to make writing IRC bots more complicated?

The value of literate programming is proportional to the novelty of the material it documents.

You captured 18 months of personal depression in 7 lines :)

Any time a new idea comes along, there's always someone who claims everyone needs to learn it, and that it needs to become a part of school curriculum.

In my opinion, the ability to think laterally is far more valuable than the ability to think 'computationally'. The latter is comprised of essentially one pattern of thinking -- procedural -- while the former opens one to an infinite set of patterns with which to think.

The computer is a decent vehicle for exploring patterns or modes of thinking once you've discovered them, but the goal should be to explore the pattern, not the vehicle.

I think the definition of perfect code depends on whether the computer is the end or the means. If it's the end, then there may never be perfection.

This project is solving the wrong problem. It's not the interfaces of web browsers that suck, it's the gigabytes of RAM they consume.

Avoid writing code to begin with by leveraging existing tools, or build better tools so you don't have to write better code (and share with the rest of the world :).

rob pike compared using unix to listening to david cassidy every day for four decades. we don't need another unix. we need a dramatically different world-view.

i have trouble accepting the idea that fewer women in tech is a problem. it's not that i want to discourage women -- or anyone -- from going into tech. i just don't believe in encouraging anyone to do anything in particular, except what they enjoy. i'd appreciate it if someone can persuade me that the hype is true so i no longer need to feel like a black sheep. but..

for one, the fact that there are fewer women than men in any field, computing or otherwise, is neither good nor bad. the disproportionate number of women in nursing is not seen as a problem, but somehow it has become one in tech.

two, as we flood more people into professional computing, the good pay -- one of the reasons given on the wwcode website for encouraging women to enter the field -- will decrease, due to the increased supply of workers. tech is reduced to Yet Another Job, and Women Who Bgurp becomes the next YC startup.

three, the wwcode website argues that diverse teams perform better by increasing collective intelligence -- measured in what units? and when it claims that organizations with the largest representation of women leadership have a higher return on investment, how is that measured? this seems super hand-wavy to me.

lastly, the website's statement about women investing 90% of their income in their communities "when [they] make more" is not only unlikely, but is predicated on the long-term availability of good pay in professional computing, which, as i mentioned earlier, will decline at a rate proportional to the frequency with which we encourage people to enter the field.

I think Milton Friedman's negative income tax is an improvement on this idea, and has the benefit of providing more of an incentive to work.

In my limited experience working with JavaScript, I've found the lack of the following to cause more problems when writing modular, reusable code than the lack of type annotations:

* a single, definitive method for creating namespaces without using a framework or library

* a single, definitive method for defining classes and using inheritance without using a framework or library

* a single, definitive method of allowing async functions to modify the state of an object without having to declare that object in the global scope, without using a framework or library

If these problems are already solved, please let me know!

haven't linux package managers (e.g. emerge, aptitude, yum, etc.) basically solved the packaging problem?

looks great. but i can't help but think it would save everyone a lot of time -- maybe not up-front, but in the long-run -- if we wrote these frameworks in c and just wrote language bindings for r, python, ruby, etc. why are we rebuilding good frameworks over again just because they're not written in our preferred language?

"Hashes are always O(1) reads, inserts and writes."

Maybe, once you've found a location to read, insert, or write to. The author neglects the runtime cost required for the hash algorithm itself, which may not be trivial; computing the hash of a string key is typically an O(n) operation.

Furthermore, unless a suitable table size is selected, integer keys (should one use a map like an array) will eventually hash to the same value, requiring even more time to iterate through all the remaining values that match that key until the desired value is found.

"I don’t know why you would ever use [a linked list] over an array (or a hash)..."

Here's why: because arrays take up space whether you use it or not. Linked lists don't suffer from this problem, but at the cost of 1-2 pointers per item. Has the author seriously never managed memory before? Please tell me this article is a joke.