Level 1: Clarifications. I also think of these as sanity checks, I may even start the comment with something like I may be completely off the base here... or Just to sanity check...
Clarifications - 1st type of MR comments
Level 1: Clarifications. I also think of these as sanity checks, I may even start the comment with something like I may be completely off the base here... or Just to sanity check...
Clarifications - 1st type of MR comments
The problem is that a lot of old school website devs can write jQuery and very very little actual JavaScript.
This happens to be true of many of the new/up-to-date Web developers I see, too.
Anecdote: I never really did StackOverflow, either as a reader or a contributor. One day several years ago (well after StackOverflow had taken off), I figured that since I see people complain about JS being confusing all the time and since I know JS well, then I'd go answer a bunch of questions. The only problem was that when I went to the site and looked at the JS section, it was just a bunch of jQuery and framework shit—too much to simply ignore and try to find the ones that were actually questions about JS-the-language. "I know," I thought. "I'm in the JS section. I'll just manually rewrite the URL to jump to the ECMAScript section, which surely exists, right? So I did that, and I just got redirected to the JS section...
now something breaks elsewhere that was unsuspected and subtle. Maybe it’s an off-by-one problem, or the polarity of a sign seems reversed. Maybe it’s a slight race condition that’s hard to tease out. Nevermind, I can patch over this by changing a <= to a <, or fixing the sign, or adding a lock: I’m still fleshing out the system and getting an idea of the entire structure. Eventually, these little hacks tend to metastasize into a cancer that reaches into every dependent module because the whole reason things even worked was because of the “cheat”; when I go back to excise the hack, I eventually conclude it’s not worth the effort and so the next best option is to burn the whole thing down and rewrite it…but unfortunately, we’re already behind schedule and over budget so the re-write never happens, and the hack lives on.
I'm having real difficulty understanding what is going on here and in what situations such cascading problems occur.
Is it a case of under-abstraction?
as if the only option we had to eat was factory-farmed fast food, and we didn’t have any way to make home-cooked meals
See also An app can be a home-cooked meal along with this comment containing RMS's remarks with his code-as-recipe metaphor in the HN thread about Sloan's post:
some of you may not ever write computer programs, but perhaps you cook. And if you cook, unless you're really great, you probably use recipes. And, if you use recipes, you've probably had the experience of getting a copy of a recipe from a friend who's sharing it. And you've probably also had the experience — unless you're a total neophyte — of changing a recipe. You know, it says certain things, but you don't have to do exactly that. You can leave out some ingredients. Add some mushrooms, 'cause you like mushrooms. Put in less salt because your doctor said you should cut down on salt — whatever. You can even make bigger changes according to your skill. And if you've made changes in a recipe, and you cook it for your friends, and they like it, one of your friends might say, “Hey, could I have the recipe?” And then, what do you do? You could write down your modified version of the recipe and make a copy for your friend. These are the natural things to do with functionally useful recipes of any kind.
Now a recipe is a lot like a computer program. A computer program's a lot like a recipe: a series of steps to be carried out to get some result that you want. So it's just as natural to do those same things with computer programs — hand a copy to your friend. Make changes in it because the job it was written to do isn't exactly what you want. It did a great job for somebody else, but your job is a different job. And after you've changed it, that's likely to be useful for other people. Maybe they have a job to do that's like the job you do. So they ask, “Hey, can I have a copy?” Of course, if you're a nice person, you're going to give a copy. That's the way to be a decent person.
If you’re a coder, when’s the last time you just quickly built something to solve a problem for yourself or simply because it was a fun idea?
And how future-proof was the result or how easy was it to make sure you could share it with others in a form that they could make use of (and not be dependent on you or some third-party or their internet connection)?
This column will continue only if I hear from people who use literate-programming systems that they have not designed themselves. and it did not continue.
To keep tiny mistakes from crashing our software or trashing our data, we write more software to do error checking and correction.
This is supposed to be the justification for increasing code size. So what's the excuse for projects today? Software of today is not exactly known for adding more "error checking and correction". It feels more like growth for growth's sake, or stimulating some developer's sense of "wouldn't it be cool if [...]?".
suppose when you needed to make a permanent edit to the style sheet on your homepage, you opened up the CSS viewer, made the edit, and the result persists—not just in your browser, but by changing the very style sheet itself
an acknowledgement of network effects: LP is unlikely to ever catch on enough to be the majority, so there needs to be a way for a random programmer using their preferred IDE/editor to edit a "literate" program
This is part of the reason why I advocate for language skins for comparatively esoteric languages like Ada.
in other words, there would be no "weave" step
Well, there could still be a weave step—same as there is like with triple scripts (to go from compilation form back to the original modules) or with Markdown, which should be readable both as plain text and in rendered form.
memory usage and (lack of) parallelism are concerns
Memory usage is a concern? wat
It's a problem, sure, if you're programming the way NPMers do. So don't do that.
This is a huge problem I've noticed when it comes to people programming in JS—even, bizarrely, people coming from other languages like Java or C# and where you'd expect them to at least try to continue to do things in JS just like they're comfortable doing in their own language. Just because it's there (i.e. possible in the language, e.g. dynamic language features) doesn't mean you have to use it...
(Relevant: How (and why) developers use the dynamic features of programming languages https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf)
The really annoying thing is that the NPM style isn't even idiomatic for the language! So much of what the NodeJS camp does is so clearly done in frustration and the byproduct of a desire to work against the language. Case in point: the absolutely nonsensical attitude about always using triple equals (as if to ward off some evil spirits) and the undeniable contempt that so many have for this.
Interesting that this is written by a BSD guy.
local a (e.g. aPoint) param p (e.g. pPoint) member instance m (e.g. mPoint) static s (e.g. sPoint)
This is really only a problem in languages that make the unfortunate mistake of allowing references to unqualified names that get fixed up as if the programmer had written this.mPoint or Foo.point. Even if you're writing in a language where that's possible, just don't write code like that! Just because you can doesn't mean you have to.
The only real exception is distinguishing locals from parameters. Keep your procedures short and it's less of a problem.
This can get much worse than the above example; the number of \’s required is exponential in the nesting depth. Rc fixes this by making the backquote a unary operator whose argument is a command, like this: size=‘{wc -l ‘{ls -t|sed 1q}}
for parsing and converting a superset of Markdown
We overload the meaning of "GFM" to mean "GitLab Flavored Markdown", which is a superset of GitHub's version. However it can cause confusion as they are not the same thing.
The argument used to propose its use is to avoid the construction of multiple volatile objects. This supposed advantage is not real in virtual machines with efficient garbage collection mechanisms.
Consider a Sufficiently Smart Compiler/Runtime where a multiply-instanced class has the exact same runtime characteristics as code that has been hand-"tuned" to use a singleton.
When creating a singleton, the author is making the assumption that no program will ever have any reason to have more than one instance of the class. This is a big assumption, and it often proves wrong later on when the requirements change.
Avoid singletons from the start.
Stop using TODO for everything in your comments that requires you to do something later.
Possible alternatives of TODO: * FIXME - something is broken * HACK/OPTIMIZE - the code is suboptimal and should be refactored * BUG - there is a bug in the code * CHECKME/REVIEW - the code needs to be reviewed * DOCME - the code needs to be documented (either in codebase or external documentation) * TESTME - the specified code needs to be tested or that tests need to be written for that selection of code
Instead read this gems brief source code completely before use OR copy the code straight into your codebase.
I'm not sure what $name is
This post is filled with programming/debugging missteps that are the result of nothing other than overlooking what's already right in front of the person who's writing.
comparing the event and window.event isn't enough to know if event is a variable in scope in the function or if it's being looked up in the window object
Sounds like a good use case for an expansion to the jsmirrors API.
Then, if the string can be represented as ASCII, only one byte of memory is used per character. If the string uses more extended characters, it might end up using as many as 4 bytes per character. We can see how much memory an object needs using sys.getsizeof()
"a" takes less bytes than "❄", which takes less bytes than "💵"
I feel like better code visualization would solve a lot of my problems. Or at least highlight them.
The other commenter talks about a typical sw.eng. approach to visualization (flame graphs), but I want programs visualized as a manufacturing/packing/assembly line on a factory floor. Almost like node editors like Unreal's Blueprints, but in three dimensions, and shit visibly moving around between tools on the line in a way that you can actually perceive. Run the testcase on a loop, so you have a constant stream of "shit visibly moving around", and it runs at fractional speed so the whole process takes, say 10 seconds from front-to-back instead of near instantaneously like it normally would (and allow the person who's debugging to control the time scaling, of course). You find bugs by walking the line and seeing, "oh, man, this purple shit is supposed to be a flanged green gewgaw at this point in the line", so you walk over and fix it.
(This is what I want VR to really be used for, instead of what's capturing people's attention today—games and lame substitutes for real world interaction like Zuckerberg is advocating for.)
The Code Review Pyramid
Let’s look at a recent paper by Xia, Bao, Lo, Xing, Hassan, & Li entitled Measuring Program Comprehension: A Large-Scale Field Study with Professionals and published in IEEE Transactions on Software Engineering, 44, 951-976, 2018. This paper is quite interesting in that it describes in great details how the figures are obtained. And it says that Comprehension took on average ~58%.
Developers spend most of their time figuring the system out

The SE server is also responsible for building ebooks when they get released or updated. This is done using our ebook production command line toolset.
It would be great if these tools were also authored to be a book—a comprehensive, machine-executable runbook.
# Input Input: 123, Output: Input: 121, Output: Input: 111, Output: Input: 123454321, Output: Input 123123, Output: # Instruction Output true if input is a palindrome # Output Input: 123, Output: false Input: 121, Output: true Input: 111, Output: true Input: 123454321, Output: true Input 123123, Output: false
Example of using GPT-3 for programming
software will work only if we provide the tools to fix it when it goes wrong
Using named arguments is nice for languages that support it, but this is not always a possibility. Even in Python, where time.sleep is defined with a single argument named secs, we can’t call sleep(secs=300) due to implementation reasons. In that case, we can give the value a name instead.Instead of this:time.sleep(300)Do this:sleep_seconds = 300 time.sleep(sleep_seconds)Now the code is unambiguous, and readable without having to consult the documentation.
Putting units in variable names
Core: like an engine in a car. The product is meaningless without it.Necessary: like a car’s spare wheel. It’s rarely used but when needed, its function decides the success of the system.Added value: like a car’s cup-holder. It’s nice to have but the product is perfectly usable without it.Unique Selling Point: the main reason people should buy your product instead of your rivals. For example, your car is the best off-road vehicle.
4 categories of software features
front-end dumpster fires, where nothing that is over 18 months old, can build, compile or get support anymore. In my day job, I inherit "fun" tasks as 'get this thing someone glued together with webpack4 and frontend-du-jour to work with webpack5 in 2022
Literate programs allow you to answer these questions naturally.
And in environments without tangle and weave, you can get pretty far by just making sure to write code top-down.
In 1994, The Unix-Haters Handbook was published containing a long list of missives about the software—everything from overly-cryptic command names that were optimized for Teletype machines, to irreversible file deletion, to unintuitive programs with far too many options. Over twenty years later, an overwhelming majority of these complaints are still valid even across the dozens of modern derivatives. Unix had become so widely used that changing its behavior would have challenging implications. For better
Object hierarchies are very different from relational hierarchies. Relational hierarchies focus on data and its relationships, whereas objects manage not only data, but also their identity and the behavior centered around that data.
it doesn't mean that we actually want all the instances in the heap to be reinitialized
It's conceivable that people would find it overly cumbersome having to deal with this when prototyping from a REPL—enough to consider it a bad experience to keep them from trying.
A live IDE could recognize that the user probably doesn't want that to happen for a given object, since it only just appeared a little while ago, so it should offer some fixup to save time for the user.
The PA group has given the name cliche to commonly used programming constructs.
Later the industry began to call them "patterns" (cf Gabriel).
Another unanchored thought I've had on these matters is coming around to viewing namespace collision as a feature, not a bug. If a programming system is designed to allow you to link against a given module and more or less ignore any and every transitive dependency that this will bring in—because the programming environment makes it excessively easy to do so—then that's a pretty strong reason to consider whether or not that approach to information hiding is actually an anti-feature.
On the other hand, if during your work on a program you have to reconcile the names used within the system (i.e., such that no two module names collide), then it subtly encourages you to make sure you are able to account for every module that your program depends on.
People reflexively assume that this would make it cumbersome (or even intractable) to work on a program any larger than a toy, but empiraclly we can observe that a single, shared namespace can, by and large, scale way better than these protests would lead us to believe. It's not out of the question that a project might reach, say, 100kloc with very little friction arising as a consequence of this sort of forced reckoning. (And it's worth considering of the friction that it does impose: is it any worse than the costs we've observed over the last ~10 years from the systems that set out to solve this problem?)
Understanding a strange codebase is hard.
John Nagle is fond of making the observation that there are three fundamental and recurring questions that dominate one's concerns when programming in C.
More broadly (speaking of software development generally), one of the two big frustrations I have when dealing with a foreign codebase is the simple question, "Where the hell does this type/function come from?" (esp. in C and, unfortunately, in Go, too, since the team didn't take the opportunity to fix it there when they could have...). There's something to be said for Intellisense-like smarts in IDEs, but I think the criticism of IDEs is justified. I shouldn't need an IDE just to be able to make sense of what I'm reading.
The other big frustration I often have is "Where does the program really start?" Gilad Bracha seems to really get this, from what I've understood of his descriptions about how module definitions work in Newspeak. Even though it's reviled, I think Java was really shrewd about its decisions here (and on the previous problem, too, for that matter—don't know exactly where FooBar comes from? welp, at least you can be reasonably sure that it's in a file called FooBar.java somewhere, so you can do a simple (and cheap) search across file names instead of a (slow, more expensive) full-text search). Except for static initializers, Java classes are just definitions. You don't get to have live code in the top-level scope the way you can with JS or Python or Go. As cumbersome as Java's design decision might feel like it's getting in your way when you're working on your own projects and no matter how much you hate it for making you pay the boilerplate tax, when it comes to diving in to a foreign codebase, it's great when modules are "inert". They don't get to do anything, save for changing the visibility of some symbol (e.g. the FooBar of FooBar.java). If you want to know how a program works, then you can trace the whole thing, in theory, starting from main. That's really convenient when it means you don't have to think about how something might be dependent on a loop in an arbitrary file that immediately executes on import, or any other top-level diddling (i.e. critical functionality obscured by some esoteric global mutable state).
too many of the coders I know would not honestly attempt it; they are in too much of a hurry to get the code written
C Interview Questions
Curated list of basic to advanced C Interview Questions to ace your interview from InterviewBit
the guide shall be written in such a way that all we have to do is produce the guide itself and then a computer can do the heavy lifting—where we might otherwise expect a separate, possibly GUI-driven, "app" to be created for the end user to interact with, we accomplish the same effect by making the guide very detailed—in part also an attempt to evoke the style and quality of old equipment operation and repair manuals that used to be available, when such manuals could be expected to include e.g. full schematics. If done correctly, this should be sufficient for the guide itself to be interpretable by a machine.
"comprehensive codebook"?
"Context" manipulation is one of big topic and there are many related terminologies (academic, language/implementation specific, promotion terminologies). In fact, there is confusing. In few minutes I remember the following related words and it is good CS exam to describe each :p Thread (Ruby) Green thread (CS terminology) Native thread (CS terminology) Non-preemptive thread (CS terminology) Preemptive thread (CS terminology) Fiber (Ruby/using resume/yield) Fiber (Ruby/using transfer) Fiber (Win32API) Generator (Python/JavaScript) Generator (Ruby) Continuation (CS terminology/Ruby, Scheme, ...) Partial continuation (CS terminology/ functional lang.) Exception handling (many languages) Coroutine (CS terminology/ALGOL) Semi-coroutine (CS terminology) Process (Unix/Ruby) Process (Erlang/Elixir) setjmp/longjmp (C) makecontext/swapcontext (POSIX) Task (...)
This (somewhat contrived) example allows the inner loop to abandon processing early: callcc {|cont| for i in 0..4 print "\n#{i}: " for j in i*5...(i+1)*5 cont.call() if j == 17 printf "%3d", j end end }
Good stuff about big modular javascript program, Home Assistant.
Make simple changes to (some carefully chosen fork of) any project in an afternoon, no matter how large it is. Gain an hour’s worth of understanding for an hour’s worth of effort, rather than a quantum leap in understanding after a week or month of effort.
Accessibility is more important, after all, than Kartik says it is (elsewhere; cf recent Mastodon posts).
Once you've written the imperative library/util code once, your components are super slim and completely reactive/declarative. Wow.
The yieldable objects currently supported are: promises thunks (functions) array (parallel execution) objects (parallel execution) generators (delegation) generator functions (delegation) Nested yieldable objects are supported, meaning you can nest promises within objects within arrays, and so on!
The power of await is that it lets you write asynchronous code using synchronous language constructs.
<a href="https://web.hypothes.is/help/" class="hyp-u-horizontal-spacing--2 hyp-u-layout-row--center HelpPanel-tabs__link" target="_blank" rel="noopener noreferrer"><span>Help topics</span>
How to get remote control over the Hypothesis sidebar (one way, at least):
https://hypothes.is/app.html with a site-specific URL fragment; you can get the actual URL from the devtools JS console with document.documentURI, or right-clicking the sidebar and selecting "View Frame Info")From the secondary tab ("foobar" opened by click in step #6) you should now have unrestricted, scriptable access to the DOM of the original sidebar iframe, using e.g. the JS console in devtools instance or a bookmarklet applied to the secondary tab—access it as window.opener.
Smalltalk image is unlike a collection of Java class files in that it can store your programs (both source and compiled bytecode), their data, and execution state. You can quit and save your work while some code is executing, move your image to an entirely different machine, load your image… and your program picks up where it left off.
Advantage of *Smalltalk** VM
Smalltalk has a virtual machine which allows you to execute your code on any platform where the VM can run. The image however is not only all your code, but the entire Smalltalk system, including said virtual machine (because of course it’s written in itself).
Smalltalk has a VM
This was because dynamic typing doesn’t give the safety net that static typing does. So you write more tests. Which is a good thing.
Tests are a good thing, but not all devs are even aware of the loss of safety net and so there's no guarantee that using a dynamic language results in more tests.
Using tests and static-types together would mean that there's whole categories of bugs that get eliminated while also getting more coverage for less lines of test-code.
I think one of the ways that remote work changes this is that I can do other things while I think through a tricky problem; I can do dishes or walk my dog or something instead of trying to look busy in a room with 6-12 other people who are furiously typing because that's how the manager and project manager understand that work gets done.
Way work often looks like during remote dev work
What is an assembler language?
https://en.itpedia.nl/2019/11/11/wat-is-een-assembler-taal/
An #assembler_language is a low-level programming_language designed for a specific processor type. We can produce Assembler by compiling #source_code from a high-level programming language (such as C / C ++). But we can also write #programs in this language ourselves. In turn, we can convert Assembler_code into machine_code using an assembler.

The main idea behind the space-based pattern is the distributed shared memory to mitigate issues that frequently occur at the database level. The assumption is that by processing most of operations using in-memory data we can avoid extra operations in the database, thus any future problems that may evolve from there (for example, if your user activity data entity has changed, you don’t need to change a bunch of code persisting to & retrieving that data from the DB).The basic approach is to separate the application into processing units (that can automatically scale up and down based on demand), where the data will be replicated and processed between those units without any persistence to the central database (though there will be local storages for the occasion of system failures).
Space-based architecture
Microservices architecture consists of separately deployed services, where each service would have ideally single responsibility. Those services are independent of each other and if one service fails others will not stop running.
Microservices architecture
First of all, if you know the basics of architecture patterns, then it is easier for you to follow the requirements of your architect. Secondly, knowing those patterns will help you to make decisions in your code
2 main advantages of using design patterns:
Mikrokernel Architecture, also known as Plugin architecture, is the design pattern with two main components: a core system and plug-in modules (or extensions). A great example would be a Web browser (core system) where you can install endless extensions (or plugins).
Microkernel (plugin) architecture
The idea behind this pattern is to decouple the application logic into single-purpose event processing components that asynchronously receive and process events. This pattern is one of the popular distributed asynchronous architecture patterns known for high scalability and adaptability.
Event-driven architecture: high scalability and adaptability
It is the most common architecture for monolithic applications. The basic idea behind the pattern is to divide the app logic into several layers each encapsulating specific role. For example, the Persistence layer would be responsible for the communication of your app with the database engine.
Layered architecture
A model for understanding equality comparisons
Another option is the use the functional library Ramda, while the syntax may be a bit different from the Ruby and Pure JS version, I find it to be more declarive: list = [null, "say", "kenglish", "co", null] R.reject(R.isNil, list) // return new array [ 'say', 'kenglish', 'co' ]
In my method, program segments are embedded in the midst of a word processor document--like raisins in cake--so that the emphasis is on the explanation rather than the code.
Any language or system that does not allow full flowing and arbitrarily long comments is seriously behind the times. That we use escape characters to “escape” from code to comment is backwards. Ideally, comment should be the default, with a way to signal the occasional lines of code.
Sounds like literate programming.
I'm not a naturally quick programmer. Learning to program was a real struggle for me and I was pretty slow at it for a long time (and I still am in aspects that I haven't practiced). My "one weird trick" is that I've explicitly worked on speeding up things that I do frequently and most people have not.
Ungar, around @1:00:00:
I try to explain to people that the notion of compiler is broken. Of course I learned this from Smalltalk, but what we want to build is experiences--artificial realities that convince you that your source code is real. It's directly executed. There's no lag between editing and running[...] The environment stresses things in your program, not tools--which is another rant I have. It's this whole idea that we want to put you in an artificial reality--I got that from Randy [Smith]--in which it's easy and natural and low-cognitive-burden to get the computer to do what you want it to do, rather than running language translators that turn weird strings of text into bits the machine can run
Wet behind the ears: the ones that have just started working as a professional programmers and need lots of guidance. Sort of knows what they are doing: professional programmers, who have sort of figured what is going on and can mostly finish their tasks on their own. Experienced: the ones who have been around the block for a while and are most likely the brains behind all the major design decisions of a large software project. Coworkers usually turn to them when they need advice for a hard technical problem. Some programmers will never reach this level, despite their official title stating otherwise (but more on that later).
3 levels of programming experience:
The problem with the first approach is that it considers software development to be a deterministic process when, in fact, it’s stochastic. In other words, you can’t accurately determine how long it will take to write a particular piece of code unless you have already written it.
Estimation around software development is a stochastic process
We would prefer: stay within single host language, but make code lookas declarative as possible.
you're guilty of making the same mistake as people who used to say that templates and styles and JavaScript should be in separate files
At last, another one realizing that they ha dbeen structuring MVC web-apps counter-intuitively for decades.
Build data pipelines, the easy way
orchest
This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from. This is but one example of what I’ve dubbed the Law of Leaky Abstractions:
I don’t even minify page assets
Good. Don't. The number of people who think this is a virtue is frightening. The rationale is usually not well-reasoned and whatever values they pretend to hold can almost always be shown to be hollow.
At the same time, details about programming language semantics are quite precise and when articles like this get things sort of wrong, it just leads to more confusion.
This post is about all the major disadvantages of Julia. Some of it will just be rants about things I particularly don't like - hopefully they will be informative, too.
It seems like Julia is not just about pros:
I really hope they keep breaking it. Being the lead on a library for several years, most of the forced refactors were pretty straight forward and in almost every case made our code either more sound or easier to be consumed. Now I work on a runtime that embeds TypeScript and 3.5.1 has broken some code, thought it took me all of about 15 minutes to make the changes to adopt it, and in every case, it broke because we were being a bit loose with the types. While it didn't find any bugs, it made the code more "safe".
I really hope they keep breaking it.
Changing every built-in function to accept anys would also "break" no one, but that doesn't make it a good idea. Part of TypeScript's value proposition is to catch errors; failing to catch an error is a reduction in that value and is something we have to weigh carefully against "Well maybe I meant that" cases.
Aside to global and local scope there is also something one could call a “block” scope. This is not an “official” type of scope, but it does exist. Block scope was introduced to JavaScript as a part of the ES6 specification. It was introduced along with two new types of variables let and const.
In javascript prettier-ignore ignores the next block, so what I did was just make the next few lines a block.
Rubyists don't call these things annotations. One of the things I like doing is to find common techniques that cross languages, for me this is a common technique and 'annotation' seems like a good generic word for it. I don't know if Rubyists will agree.
Languages may provide annotations in ways that don't reflect the syntax of the language
When writing about programming, I prefer to use 'annotation' as the general term. Although .NET was first, the word 'attribute' is just too widely used for different things.
An annotation on a program element (commonly a class, method, or field) is a piece of meta-data added to that program element which can be used to embellish that element with extra code.
When people talk about internal DSLs I see two styles: internal minilanguages and language enhancements.
Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially
Optimism is an occupational hazard of programming: feedback is the treament.
We can also define these properties for data types that we do not control, for example providing a custom way of hashing a data type implemented by someone else
However, there is a definite trade off in these three snippets. The first one is overly specific but is understandable to any Scala programmer. The last one is beautiful and elegant if you understand the necessary concepts but incomprehensible otherwise.
ZIO ecosystem libraries generally do not directly expose any functional abstractions but still expose a highly compositional interface because their design is based on algebraic properties like this. Users don't have to learn about these abstractions unless they want to, they just get to benefit from better library design.
Open source is not a good business model.If you want to make money do literally anything else: try to sell software, do consulting, build a SAAS and charge monthly for it, rob a bank.
Open-source software is not money friendly
The only way for one person to even attempt cross-platform app is to use a UI abstraction layer like Qt, WxWidgets or Gtk.The problem is that Gtk is ugly, Qt is extremely bloated and WxWidgets barely works.
Why releasing cross-platform apps can make them ugly
The visual and spacing differences between proportional and monospaced fonts
Proportional vs Monospaced fonts:

https://blog.jonudell.net/2021/07/21/a-virtuous-cycle-for-analytics/
Some basic data patterns and questions occur in almost any business setting and having a toolset to handle them efficiently for both the end users and the programmers is an incredibly important function.
Too often I see businesses that don't own their own data or their contracting out the programming portion (or both).
I try and act like a scientist. If I have a hypothesis about how this code is supposed to work, I test that hypothesis by changing the code, and seeing if it breaks in the way I expect. When I discover that my hypothesis is flawed, I might detour from the tutorial and do some research on Google. Or I might add it to a list of "things to explore later", if the rabbit hole seems to go too deep.
Soudns like shotgun debugging is not the worst method to learn programming
Things never go smoothly when it comes to software development. Inevitably, we'll hit a rough patch where the code doesn't do what we expect.This can either lead to a downward spiral—one full of frustration and self-doubt and impostor syndrome—or it can be seen as a fantastic learning opportunity. Nothing helps you learn faster than an inscrutable error message, if you have the right mindset.Honestly, we learn so much more from struggling and failing than we do from effortless success. With a growth mindset, the struggle might not be fun exactly, but it feels productive, like a good workout.
Cultivating a growth mindset while learning programming
I had a concrete goal, something I really wanted, I was able to push through the frustration and continue making progress. If I had been learning this stuff just for fun, or because I thought it would look good on my résumé, I would have probably given up pretty quickly.
To truly learn something, it is good to have the concrete GOAL, otherwise you might not push yourself as hard
Multiple inheritance is one of the object oriented feature where a class or a sub class can inherit features from more than one parent class or super class.
https://www.flowerbrackets.com/multiple-inheritance-in-java/
Interface is collection of methods of abstract type (having empty body). It’s similar to Abstract class. Interface is blueprint of class. Interface specify what class must do and not how to.
A class which implements interface should define each and every method in the class. Interface is used to implement multiple inheritance in java (represent IS-A relationship).
[Huh? Pass-by-reference ALWAYS requires passing a reference by value. That's how it works. The question is whether the referenced object is a COPY of the caller's object, or an ALIAS for the user's value. Most modern languages pass by reference for non-primitive types.]
This person is confused, though it's obvious and understandable to those who've been down the road before how it happens. Most mainstream languages that are taught to be "pass by reference" are actually of the "pass by reference value" sort. Lack of exposure to languages that actually implement pass by reference is the culprit. Of course if your experience is limited to C, C++, Java, and others that use the "pass by reference value" approach, then you'll come away thinking that "pass by reference value" is what "pass by reference" means and this is what any and every language "ALWAYS requires" when setting out to implement "pass by reference"—you just don't have the appropriate frame of reference to see how it could be otherwise.
The world could benefit from a curated set of bookmarklets in the style of Smalltalk ("doIt", "printIt", etc buttons) that you can place in your bookmarks bar (or copy into a bookmarks document and open in it in your browser), where the purpose would be to allow you to:
scratch.js aims for something something similar, and though laudable it falls short of what I actually crave (and what I imagine would be be most beneficial/appreciated by the public).
The keyword data tells us this is an inductive definition, that is, that we are defining a new datatype with constructors
Inductive, since multiple constructors are generalized to a type. And as seen in this example, data types can also facilitate mathematical induction.
Useful advice for commenting code.
The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.
It’s fun but when would we ever use things like this in actual code?When it’s well tested, commented, documented, and becomes an understood idiom of your code base.We focus so much on black magic and avoiding it that we rarely have a chance to enjoy any of the benefits. When used responsibly and when necessary, it gives a lot of power and expressiveness.
In case writing to tmpfile fails for some reason, use && mv ... instead of ; mv ... -- that will keep $file from being overwritten with "bad" content.
Different ways to prepend a line: (echo 'line to prepend';cat file)|sponge file sed -i '1iline to prepend' file # GNU sed -i '' $'1i\\\nline to prepend\n' file # BSD printf %s\\n 0a 'line to prepend' . w|ed -s file perl -pi -e 'print"line to prepend\n"if$.==1' file
Johnson, Khari. ‘AI Could Soon Write Code Based on Ordinary Language’. Wired. Accessed 21 June 2021. https://www.wired.com/story/ai-write-code-ordinary-language.
(Always call super to inherit the default behavior.)
It also makes it hard to centralize type coercions and default values.
Adding Object Oriented Principles (OOP) to a functional codebase adds yet another way of writing code, reducing consistency and clarity.
Same feature in TypeScript¶ It's worth mentioning that other languages have a shortcut for assignment var assignment directly from constructor parameters. So it seems especially painful that Ruby, despite being so beautifully elegant and succinct in other areas, still has no such shortcut for this. One of those other languages (CoffeeScript) is dead now, but TypeScript remains very much alive and allows you to write this (REPL): class Foo { constructor(public a:number, public b:number, private c:number) { } } instead of this boilerplate: class Foo { constructor(a, b, c) { this.a = a; this.b = b; this.c = c; } } (The public/private access modifiers actually disappear in the transpiled JavaScript code because it's only the TypeScript compiler that enforces those access modifiers, and it does so at compile time rather than at run time.) Further reading: https://www.typescriptlang.org/docs/handbook/2/classes.html#parameter-properties https://basarat.gitbook.io/typescript/future-javascript/classes#define-using-constructor https://kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/ I actually wouldn't mind being able to use public/private modifiers on instance var parameters in Ruby, too, but if we did, I would suggest making that be an additional optional shortcut (for defining accessor methods for those instance vars) that builds on top of the instance var assignment parameter syntax described here. (See more detailed proposal in #__.) Accessors are more of a secondary concern to me: we can already define accessors pretty succinctly with attr_accessor and friends. The bigger pain point that I'm much more interested in having a succinct shortcut for is instance var assignment in constructors. initialize(@a, @b, @c) syntax¶ jsc (Justin Collins) wrote in #note-12: jjyr (Jinyang Jiang) wrote: I am surprised this syntax has been repeatedly requested and rejected since 7 years ago. ... As someone who has been writing Ruby for over 10 years, this syntax is exactly that I would like. I grow really tired of writing def initialize(a, b, c) @a = a @b = b @c = c end This would be perfect: def initialize(@a, @b, @c) end I'm a little bit sad Matz is against this syntax, as it seems so natural to me. Me too!! I've been writing Ruby for over 15 years, and this syntax seems like the most obvious, simple, natural, clear, unsurprising, and Ruby-like. I believe it would be readily understood by any Rubyist without any explanation required. Even if you saw it for the first time, I can't think of any way you could miss or misinterpret its meaning: since @a is in the same position as a local variable a would normally be, it seems abundantly clear that instead of assigning to a local variable, we're just assigning to the variable @a instead and of course you can reference the @a variable in the constructor body, too, exactly the same as you could with a local variable a passed as an argument. A workaround pattern¶ In the meantime, I've taken to defining my constructor and list of public accessors (if any) like this: attr_reader \ :a, :b def new( a, b) @a, @b = a, b end ... which is still horrendously boilerplatey and ugly, and probably most of you will hate — but by lining up the duplicated symbols into a table of columns, I like that I can at least more easily see the ugly duplication and cross-check that I've spelled them all correctly and handled them all consistently. :shrug: Please??¶ Almost every time I write a new class in Ruby, I wish for this feature and wonder if we'll ever get it. Can we please?
For attributes, methods and constructors, you can use the one of the following:
Introduce behaviour that is likely to surprise users. Instead have due consideration for patterns adopted by other commonly-used languages.
Emit clean, idiomatic, recognizable JavaScript code.
The encapsulation is enforced by the language. It is a syntax error to refer to # names from out of scope.
When defining accessors in Ruby, there can be a tension between brevity (which we all love) and best practice.
Yeah, "virtual attribute" seems like dated terminology to me, so conceptually just a method.
I see a 'virtual attribute' as something we're forced to implement when using frameworks, ORMs and the like. Something that lets us inject our code into the path of whatever metaprogramming has been put in place for us. In a simple PORO like this, I don't see how it has meaning; it's just a method. :)
Hmm, good point. Maybe so. Though I think I'm fine with calling it a virtual property here too. :shrug:
has_sauce is a "virtual attribute", a characteristic of the model that's dependent on the underlying toppings attribute.
in languages (like JavaScript and Java) where external objects do have direct access to instance vars
Setting an instance variable by going through a setter is good practice, and using two access modifiers is the way to accomplish that for a read-only instance variable
“We want to be an example of what a modern, fast web app can do,” he says. “And we want to blow a few minds while we’re at it.”
No app as and end product, really speeds up the releasing cycle, avoids the the review process both in app store and google play store, Moreover, the apple tax and upfornt developer membership cost which is 100$ / year.
Having a member in a class and initializing it like below:class Foo { x: number; constructor(x:number) { this.x = x; }}is such a common pattern that TypeScript provides a shorthand where you can prefix the member with an access modifier and it is automatically declared on the class and copied from the constructor. So the previous example can be re-written as (notice public x:number):class Foo { constructor(public x:number) { }}
The answer is no, we use a pattern where we do this, and have a `static` method for manufacturing the constructor.e.g.static from({prop1, prop2}) => new this(public prop1, public prop2)
TypeScript includes a concise way to create and assign a class instance property from a constructor parameter.
Then, people from programming communities (mainly front-end) realized that CoffeeScript is out of date and is starting to lag behind the ever-evolving Javascript environment. As of today, January 2020, CoffeeScript is completely dead on the market (though the GitHub repository is still kind of alive).
Programmers should be encouraged to understand what is correct, why it is correct, and then propagate.
new tag?:
I don't think it is too clever. I think it solves the problem idiomatically. I.e., it uses reduce, which is exactly correct. Programmers should be encouraged to understand what is correct, why it is correct, and then propagate. For a trivial operation like average, true, one doesn't need to be "clever". But by understanding what "reduce" is for a trivial case, one can then start applying it to much more complex problems. upvote.
Thanks, this was just what I was looking for! This is a perfect appropriate use of instance_eval. I do not understand the nay-sayers. If you already have your array in a variable, then sure, a.reduce(:+) / a.size.to_f is pretty reasonable. But if you want to "in line" find the mean of an array literal or an array that is returned from a function/expression — without duplicating the entire expression ([0,4,8].reduce(:+) / [0,4,8].length.to_f, for example, is abhorrent) or being required to assign to a local, then instance_eval option is a beautiful, elegant, idiomatic solution!!
I added NULLIF() to defend against division-by-zero errors.
Adapters are required to make Request globally available if it isn't already part of the target platform. It's part of the (currently undocumented) contract — see e.g. adapter-node
After suggestions from comments below, I read A Philosophy of Software Design (2018) by John Ousterhout and found it to be a much more positive experience. I would be happy to recommend it over Clean Code.
The author recommends A Philosophy of Software Design over Clean Code
What I did have going for me was what might be considered hacker sensibilities - lack of fear of computers in general, and in trying unknown things. A love of exploring, learning by experimenting, putting stuff together on the fly.
Well described concept of hacker sensibilities
Method 1: We can grab the PDF Versions of Google’s TotT episodes or create our own posters that are more relevant to the company and put them in places where both developers and testers can’t be ignored.Method 2 : We can initiate something called ‘Tip of the day’ Mailing System from Quality Engineering Department.
Ways to implement Google's Testing on the Toilet concept
They started to write flyers about everything from dependency injection to code coverage and then regularly plaster the bathrooms in all over Google with each episode, almost 500 stalls worldwide.
Testing on the Toilet (TotT) concept
Dogfooding → Internal adoption of software that is not yet released. The phrase “eating your own dogfood” is meant to convey the idea that if you make a product to sell to someone else, you should be willing to use it yourself to find out if it is any good.
Dogfooding testing method at Google
It's Faster
Makefile is also faster than package.json script
It's even more discoverable if your shell has smart tab completion: for example, on my current project, if you enter the aws/ directory and type make<TAB>, you'll see a list that includes things like docker-login, deploy-dev and destroy-sandbox.
If your shell has smart TAB completion, you can easily discover relevant make commands
Variables. Multiple lines. No more escaped quotation marks. Comments.
What are Makefile's advantages over package.json scripts
you want to pass a function as an argument to higher-order functions
Functional programming - passing functions as arguments, as opposed to data objects.
standard JavaScript advice to avoid top-level function declarations and use modern arrow syntax
This project will be great for instruction and portable reproducible science
This is what I'm aiming for with triplescripts.org. Initially, I'm mostly focused on the reproducibility the build process for software. In principle, it can encompass all kinds of use, and I actually want it to, but for practical reasons I'm trying to go for manageable sized bites instead of very large ones.
To prevent race conditions and deadlocks, we highly recommend that each of the communication channels is serviced on a separate thread that maintains its own client buffer state and messaging queue inside your application. Servicing all of the pseudoconsole activities on the same thread may result in a deadlock where one of the communications buffers is filled and waiting for your action while you attempt to dispatch a blocking request on another channel.
A good heuristic is to not trust the libraries you did not write either.
Within functions, you may want to check that you are not referencing something that is not valid (i.e., null) and that array lengths are valid before referencing elements, especially on all temporary/local instantiations.
It seems inelegant to me to split this into two different modules, one to include, the other to extend.
the key thing (one of them) to understand here is that: class methods are singleton methods
Trust this answer. This is a very common idiom in Ruby, solving precisely the use case you ask about and for precisely the reasons you experienced. It may look "inelegant", but it's your best bet.
Apparently when you create a subclass, that subclass's singleton class has # its superclass's singleton class as an ancestor.
This is a good thing. It allows class methods to be inherited by subclasses.
Learn more about the Ruby's Object, Class & Module and the method receiver chain.
Detect undesirable changes to classes made by other libraries.
if Gem::Version.new(RUBY_VERSION) < Gem::Version.new('2.1.0')
I wish to define methods within the class they belong to. Using class << self demonstrates that approach clearly — we are defining methods within the actual singleton class scope.
When we usedef self.method, though, we are defining a method across scopes: we are present in the regular class scope, but we use Ruby’s ability to define methods upon specific instances from anywhere; self within a class definition is the Class instance we are working on (i.e. the class itself). Therefore, usingdef self.method is a leap to another scope, and this feels wrong to me.
ProMotion is a RubyMotion gem that makes iOS development more like Ruby and less like Objective-C.
If this is okay, then it might even be nice if #dig took a block as well as a fallback value: [].dig(1) { 'default' } #=> "default"
Would it be desirable to specify the new object in a block? That would make it somewhat symmetrical to how Hash.new takes a block as a default value.
The distinction in computer programming between classes and objects is related, though in this context, "class" sometimes refers to a set of objects (with class-level attribute or operations) rather than a description of an object in the set, as "type" would.
a class is an implementation—a concrete data structure and collection of subroutines—while a type is an interface
Title: "goal the use case is trying to satisfy"[23]:101 Main Success Scenario: numbered list of steps[23]:101 Step: "a simple statement of the interaction between the actor and a system"[23]:101 Extensions: separately numbered lists, one per Extension[23]:101 Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.
Not sure why I find this example so interesting.
Probably because it is a human-readable outline that uses machine-readable (programming language source code) constructs, namely loops/iteration.
The format in which this is written in, then, is itself a kind of (high-level, human-oriented) programming language.
Example:
Currently, I’m working on designing the interfaces and it’s real fun!
Put another way, it’s become clear to me over time that the problems with data races and memory safety arise when you have both aliasing and mutability. The functional approach to solving this problem is to remove mutability. Rust’s approach would be to remove aliasing. This gives us a story to tell and helps to set us apart. A note on terminology: I think we should refer to aliasing as sharing. In the past, we’ve avoided this because of its multithreaded connotations. However, if/when we implement the data parallelism plans I have proposed, then this connotation is not at all inappropriate. In fact, given the close relationship between memory safety and data races, I actually want to promote this connotation.