Programming Idea

[Lorriane Nasuti]

Whenyou ask people about functional programming, you might hear jargons like monads, morphisms, or semigroups.Others may say functional programming is all about map-filter-reduce. And you may also hear talks about purity,and side effects.

What I want to do in this post is to take a look at a couple of simple concepts that make up the little ideabehind functional programming. I will tie the concepts back to code examples in JavaScript. There willbe some ReactJS code, so some familiarity with it helps, although not necessary.

The first concept is the separation of data and behaviour. Data by themselves cannot do anything, butfunctions can be used to take them in as input and then output some new data. You can picturea function as a box that take in some shape, and spits out another.

When working with data in, data out, it is important to enforce function purity. A function is pureif its output is solely determined by its input. That is, given the same input, it must always returnthe same output. Furthermore, a pure function must not have any side effects. An effect is something likewriting to database, changing a global variable, or throwing exceptions.

The second concept is more commonly referred to as higher-order functions. It simply means thatfunctions can be used as input to other functions; and that functions can output new functions.

Note: The output function from map is called a transducer. Transducers are composable transformations that are decoupled from input data. You can watch Rich Hickey's talk on transducers to learn more about them.

In the illustration above, we created a new function h that composes f and g. This new function takesa triangle as input (input of f) and outputs a circle (output of g). We can describe this in JavaScriptusing the compose function.

This allows us to start with simple functions and use composition to build up more powerful functions.The advantage of this approach is that the functions are completely modular. All you have to do is makesure that the inputs and outputs match while composing.

The mapVideos function that we previously implemented takes an array of VideoJSON objects as input, andouputs an array of Video objects (mapVideos :: [VideoJSON] -> [Video]). However, the YouTube API actually nests the array of videoJSON objects inside a structure like this:

To implement this, we will need a way to determine if the search has not been performed. We can use Eitherto achieve this, and change the searchVideos function to return Task Error (Either Empty [Video])instead of Task Error [Video].

The power of the functional approach is that what works in the small also works in the large. We started witha simple function makeUrl, and eventually ended up with the more powerful function searchVideos. Along the entireway we were using the same approach of thinking about input/output types, and function composition.

A nice benefit of having these pure functions is that we can easily use and test each of them separately. For example,the lift(lift(toVideos)) function can be called with input of type Task Error (Either e ResponseJSON).

These three basic concepts will help you keep your application more modular by allowing you tomix and match functions together (like a Lego!) as long as their types match up. This functional approach is something that works bothin the small and in the large.

I think it is really a font problem, and maybe one solution is to either use ρ in a certain part of your code or p, but not both (too close to each other).

Or one uses speaking variables (instead of those from the paper) instead. Though for points p,q I also prefer to use p and q. But maybe the rho has a nice different constant name?

You can see how close we can make the programming language to the mathematical notation. It turns out that it greatly simplified debugging and reduced the errors. I try to avoid, however, UTF-8 symbols in the API (like in keywords) but I am also starting to change my mind even in this point.

For me being able to write \rho and it renders as ρ in Julia code is really a Godsend. When working with equations based on physical models, where each variable has a symbolic but also physical meaning, equations just stand out so much clearer.

Being able to look at the equation in paper and find it very faithfully represented in Julia code is so helpful for not losing touch with the physics. And I also like for when I write some code using waves etc.

Of course bugs, issues, misunderstandings can occur, but they can also happen without it. I have not heard of any terrible example as of now where not being able to spot a rho, leads to 1 month of debugging etc.

The problem described here is, not inherent to the Julia language but a problem inherent to physics and math in general. Where you often have the problem of not being able to easily distinguish certain letters. Especially when it comes to handwriting aswell. Just as an example we would often write Poisson Brackets with the Greek letter Xi. If you have ever written that by hand you will quickly see how fast the Xi deterioates into some weird squiggle. Similar things with i and j when written as subscripts.

There is no inherent solution to this problem that is not going against the established practices in Physics and Maths. So the best way is imo to try and avoid where reasonable and otherwise just always make sure you know that there are easily mistakable variables. Possibly use a subscript on one of them.

Otherwise @Ronis_BR has the best explanation for why this is a good feature in general.

I know what you are saying, but part of that mess in Fortran is just Fortran being Fortran (2.0d0 instead of 2). And it still takes five lines in Julia compared to six in Fortran. Breaking up the expression might be a good idea anyway.

Well, avoiding Unicode in API (or at least giving an option not to use it) is good. But (as someone pointed out already), code is read more often than it is written. So we should try to make the graphical presentation of the internal code (i.e. not API) as easy on the reader as possible. The ability of readers to affect the graphical presentation of Unicode is typically limited (viz Github), and hence use of problematic symbols should be prohibited, and use of other symbols should be considered from the point of view of visual confusion (viz \rho vs p vs rho etc.).

If I am writing code which implements some physics concept, and I expect my code to be read by fellow physicists who have similar training to me, then the most appropriate notation and conventions to clearly communicate ideas are typically going to involve a lot of unicode and single letter variables.

While code with non-ascii symbols can be very nice to read, it is normally less nice to write. Even in environments where they are supported, it can be difficult to find out how to write them, and awkward to do so.

Interviewers will be interested in what kind of work you have done before (whether for a programming job or more generally). If you are the sort of person who gets a bit nervous at an interview, and might forget to mention something in the heat of the moment, a portfolio provides you with a handy reminder of what work you have done, to talk about.

Images showing your past work (e.g. screenshots, for a programming interview) are a particularly good idea to include, if your work had a suitable visual depiction. From the interviewer's perspective, seeing an image depicting the work can really help to quickly get an overall picture of what the interviewee is talking about. Also, if you end up explaining some technical point about the work, an image might be handy to point to, to illustrate.

If you are not sure whether to include a screenshot (or another document) or not, try imagining yourself in the shoes of the interviewer and ask yourself whether this would help the interviewer see what you have to offer better. I find it hard to imagine whether examples of code would help, unless an interviewer has specifically requested them.

Yes, of course. The interviewer's job is to evaluate you in order to determine if you can get things done. A proof of that is if you show him past things that you got done. Actually, since we're talking about programming, there are TONS of ways you can do this:

In conclusion: software companies look for passionate employees. For most of them, this means someone who works on his own personal projects outside of the regular job. Maybe this is a fair assumption/expectation, maybe not; it's just there. Show them you're passionate by showing them your portfolio, it always helps :) .

Yes, I did exactly that. I sent in a portfolio with short descriptions and screenshots with my application. I also print it out and brought my App to the interview. Every interviewer I talked to responded positively to it.

Hello, I was wondering a few things. A Friend of mine gave me a bunch of attiny1614 chips that have i2c and spi on them. I was surprised to see that. But that was a few months back. I haven't find anything with them because of the limited of programming space.

The data sheet shows 16KB flash (program) memory, 2KB SRAM, and 256 Bytes of EEPROM. As far as I know EEPROM cannot be used for program code. That is half the flash memory of the atmega328 used in the UNO/Nano, so still quite useful.

I'm trying to program the chip. And it looks like i ran out of programming memory. I have a oled on it 3 temperature sensors, A Sd card module for logging and code for menu for the screen. Plus 4 push buttons.

Only thing i can do is take some stuff maybe out to free up some place. Like the menu. Because i added the memory to be able to view the logging from the Oled. I can take the Sd card out and just read it on a pc. Maybe also take out the push buttons and code for the menu to free up and space and also take out the menu maybe just have it displaying just the temperatures. total comes out to 24k with everything in it.

3a8082e126