willberman

+1 on vim with fzf and rg being enough for almost any task. I use that setup for most things and then when I need something with a little more syntactic awareness, I pop open my IDE.

I think problem is that your argument seems to come from a prior point of view, and doesn't assume good faith on the behalf of people working on smart contract problems (declaring them in whole fundamentally unethical). I would suggest that a better way to pose your point of view would be to ask, "Are there ways to mitigate the automatic triggering of actions in smart contracts?" Posing your point of view as a question like this would be more likely to foster a healthy discussion because there are certainly ways to mitigate the extent of automatic actions (multisigs etc...). And who knows, everyone might learn something as a result of the discussion!

Disclosure: I work in the cryptocurrency space and generally think hackernews doesn't know how to have productive discussions about cryptocurrency.

I don’t necessarily agree with either of those.

Maybe a college tells me that a particular type of extra-curricular wasn’t valued as highly as I thought it was and I elect to pursue something different in undergrad (I wouldn’t recommend this but to each their own). The feedback would also provide relevant data points to future applicants if chosen to be shared.

There are plenty of examples of students who are accepted/rejected to schools which you wouldn’t expect.

There's still lots of relevant work to do deeper in the stack. It might just not be at large internet scale companies (I doubt this but lets assume it's true). Most every university has a systems research lab doing interesting things. I think I paged through 5 different professor's websites in CMU's systems department the other month and found 9-10 interesting projects.

I would prefer if schools just gave as concrete as possible feedback for why individual applicants are or are not admitted.

i.e. Congrats, you got accepted. Your GPA ranked in the top $X percentile of our admitted class and your engagement in robotics was astonishing.

or

You were not admitted because while your GPA was excellent, we did not see sufficient community engagement in your extracuriculars.

Do you mind being specific on how there are no longer hard engineering problems to be solved?

For any point of view on AI, I can probably find a decent number of non technical people who hold that POV. Technical illiteracy is a significant problem imo.

Workflow on midsized personal project with editor that I'm comfortable with and have customized over the majority of time I've been programming: work.

Look, obviously VS Code has emacs beat in the vast majority usability features. Emacs works for a lot of what I work on. For the things it doesn't work for, I use the tool that works better.

I have lots of personal qualms with emacs, but to declare it "maximally unsuitable," is overkill.

Different things work for different people, but I'll give you my two cents. I got through college entirely through self study.

What works for me is reading a textbook and re-writing out any concept in the textbook in my own words until I understand it. Afterwards I do practice problems or a project to ensure I'm not lying to myself about my understanding.

If I can, I only do one topic until I'm sure I've solidified my knowledge to a sufficient degree that I won't forget it when I shift my main focus to something else.

Lastly but most importantly is be ok with failure. When you fail to learn something, take a break and then come back approaching it from an entirely different angle.

I’d give the same advice I’d give to understand anything remotely complicated.

Pick a real goal you want to accomplish that the thing you want to understand is a good fit for.

Maintain a curious mindset while trying to accomplish the goal.

To frame this in the context of emacs. Just start using it for programming. When you come across something you want it to do, google how do I make emacs <...>.

I know it sounds overly simplistic, but just trust me and try it.

Look at Chamath palihapitiya‘s description of social capital. This is what he states he’s attempting to address.

The counter argument is addressed in a debate between Reid Hoffman and Peter Thiel where Hoffman’s pov is that change occurs incrementally and what may not be considered revolutionary today (twitter, etc...) would be considered revolutionary 100 or so years ago.

I use Ubuntu as my main os for programming. I run into a few kinks every now and then, and for that I keep around a Windows and a macOS box. I’d say that Ubuntu is a sane desktop to get work done in.

It is essentially correct that the discussion on typing occurs at the least nuanced level of discourse. I've been at fault doing this myself. The distinction between different sorts of type systems and the relative conservation of the different analyses required to produce well typed programs is rarely brought up. I have a general saying that you shouldn't listen to people unless they can explain a point of view in terms of its tradeoffs. Very few real problems have absolutist solutions. I'm currently working my way through Types and Programming Languages and hope to one day present a more technical and thought out explanations of the tradeoffs present amongst untyped and the various levels of typed systems.

I second the use of iots. It has a decent learning curve but is very worth it in the end.

Could you share the 35 line library? I’m curious. I recently asked the Common Lisp subreddit why so many of their libraries lack extensive documentation and most agreed it is a wart on the language.

I made the mistake of recommending standardization of development tooling at one point. Not one of my finer moments.

Ha! I would agree that you might be taking it a bit too seriously. I was trying to make the point that sometimes things that might seem purposeless are useful simply because they are fun, scratch an itch, and might lead to a new way of looking at something. That exploratory process might be worth it in certain projects even if it introduces more bugs accidentally. I should have elaborated more rather than just leaving a quote. After all, quotation in absence of analysis contributes very little novelty.

Like most things in life, I believe the answer involves finding balance between the two :)

M-x apropos tesseract

"I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out it was an awful lot of fun. Of course the paying customers got shafted every now and then and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them setting them off in new directions and keeping fun in the house."

- Alan J. Perlis

Are you saying that the majority of the speed up is from caches and then there's a secondary, much smaller, speed up from the vectorization? Or are you saying all the speed up is from caches and I'm off base here with vectorization.

I can see how this wouldn’t be covered in an undergrad cs education. I took only a single computer architecture class which was extremely limited in scope. The only reason I knew about vectorization during undergrad is because a friend mentioned it to me once.

When I took data structures and algorithms, I believe almost every single lesson was concluded with the caveat that constants are important.

Interestingly enough I think that the core of rdf (the subject predicate object triple) is a quite elegant abstraction for knowledge graph representation.

I do agree that the layered system of different ontology languages as present in current semantic web standards is not beginner friendly, but it doesn’t mean they can’t be improved on.

I think you might be throwing the baby out with the bath water.

I have another comment on this thread that discusses the difference between research and engineering. The goal of this project is not to improve your google search results via the provided framework. That argument is an fine use of reductio ad absurdum, but it assumes a different premise than the one that the paper is addressing. The paper is an inquiry into where are we building systems that could empower user modification but for some reason or another are not. I encourage you to read the Related Work section of the paper to perhaps pattern match on other more fleshed out systems that might demonstrate the end goal in a way you've seen before.

I really like the term "view source mindset." I think it aptly applies to certain systems where you can intuit what the underlying programming is doing just by interacting with them. Definitely stealing that phrase.

This is a very relevant engineering critique, but note that this is a research project. The first step is to ask, "what if it worked this way?" After a prototype has been developed to more accurately identify what is the actual problem that is being solved, then problems like this can be addressed.

I had many interesting conversations in my undergraduate research lab trying to find the right place to draw the line between engineering and research. Problems can be more apt classified as engineering when there is high consensus on what the actual problem is. Research often addresses what question should we be asking to determine the problem that may then be solved. Most often there is a series of research and engineering iterations intertwined with each other.

I've been following this lab's work for a while and actually suggested to them that the implementation for this be based on an RDF style data model. Ontology languages are the level of abstraction up from a spreadsheet and are an atomic unit in semantic web technologies. It looks like the way this fits in to the existing architecture is that the site adapters would extract data as RDF triples.

Professor Daniel Jackson runs this lab. His book, Design by Concept, is a phenomenal read. It made me understand why software can be so unintuitive for people who haven't grown accustomed to its idiosyncrasies that I've come to internalize.

I would personally define efficacy of predictive modes to be a scientific achievement rather than engineering, but that might just be a vocab discrepancy.

Do you think it’s possible to determine how good their modeling is externally? I would assume we’d need an extensive peek behind the curtains to come to a conclusion.

Correct I think that would be a better way to put it. None of the individual building blocks seem very technically challenging, but to consistently enforce it at a company wide scale seems quite cool.