Oh, I'm very much into Elm lately. I'm aware they're out there. It just took me a long time with Elm (and others) for me to articulate a _better_ reason why `Maybe` is useful.
I agree... I wish we still had the prime character. But since Elm isn't at 1.x status yet, that earns me an "irritated smirk" rather than a table-flip. :)
Yes, I am not saying it is a big thing. It's a small thing in itself, but breaking backwards compatibility for no good reason is huge red flag for the future.
> breaking backwards compatibility for no good reason
I'd say reducing weird syntax is a perfectly good reason. How is doing this while offering an easy migration solution in an early stage language a "huge red flag"?
A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28p...)
There's a very good example in C++ of how this causes problems, where vector::clear and vector::empty are much too easy to confuse (which one of them deletes all elements, and which one of them checks if a vector is empty?). Replacing them with clear! and empty? (or is it clear? and empty!) would be a huge improvement. Whenever a language moves away from arbitrary legacy restrictions, that's a good thing.
The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.
I think that's a coding style decision, and shouldn't be part of language specification. I certainly don't feel about primes the way you do: having a function f and a function f' usually means they are sort of similar with some specific difference between them, definitely not "couldn't think of a better name". E.g., in haskell a prime often denotes a strict function, it's a better convention than having f and f_strict. Plus, how are you going to decide which unicode symbols should not be allowed? It can get a little random.
It's definitely a matter of taste, but I feel like settling for "similar except different somehow" is the same thing as "couldn't think of a better name". I would much prefer f-strict because then I don't need to be familiar with the punctuation conventions of the codebase to know how it's different from f, it's right there in English.
Edit: Plus, then you don't have to wonder if that particular function follows that naming convention; prime meaning strict isn't nearly as universally followed as ? or ! in Scheme, for instance.
I keep hearing this excuse, and to be honest I don't like it. On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse.
> I'd say reducing weird syntax is a perfectly good reason
I disagree with you on this, prohibiting the users from using the prime character has nothing to do with the language's syntax.
> On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse.
If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language.
Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's acknowledging reality. And an upside to that reality is that making these types of changes won't upset nearly as many people as it would if it were a more mature language.
> I disagree with you on this, for me it is very worrying.
> it would sound like there was some critical change to the core functionality of the language
No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so).
> 1. It confuses newbies.
Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me.
Is a language that allows Unicode characters for variable names confusing for newbies?
> 2. It's an easy character to miss.
Again, it is in my code.
> 3. It's easy to migrate away from it.
That's not an argument for removing something.
Again, my point is that is has to do with personal taste, yet Evan decided to force it to anybody who uses the language.
He could have very easily enforce it to core packages, and nobody would complain. But forcing it on my code, is worrying.
> Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me.
Until you take your personal style to Github, or coworkers...
Evan is doing a pretty good job at managing Elm – in fact I don't know any other language except maybe Swift where the rollout is planned to such a depth.
If coworkers are unhappy with it, they can (and should) make guidelines for acceptable syntax. This is no different than using camel case in Java instead of snake case (or using the $ in identifiers, which is extremely rare). If it's a problem to use it in my code on Github, you can always use somebody else's code or fork mine to change it. Maybe we should use the compiler to force every line to have a comment so we don't have any undocumented code on Github too?
The creators see it appropriate to enforce their strange preferences with dubious reasoning. The enforcement (in standard Elm format) of a 4-sized tab[1] is just another example.
Like you said I'd not have the language community enforce what is acceptable down my throat, and that conflict of preferences within a team is best solved by making style guidelines instead of having the language community spoon-feed an authoritarian preference.
I completely agree with you. Evan isn't happy just controlling what packages you can publish that use the native api on package.elm-lang.org, or what you can do in the language since the removal of signals, he wants to control even minute things like whether you use a fucking prime in a function name in your own code. It's ridiculous.
People are excited by it, and managed to deal with prime-ageddon without any major headaches (it's like basic regex search and there's even an update tool, come on).
2. Suggesting that "simply knowing more" is sufficient ignores the way many men will discount a woman's knowledge compared to a man's knowledge simply because she's a woman.
3. Can we not resort to putting people into their place to establish dominance hierarchies? What about synergistic differences? Those are tremendously valuable.
4. Many meetups can be frustrating or downright hostile to women. Even well intentioned organizers can have a difficult time attracting women if attendance is already primarily male. Let's not forget that women make about 70¢ per $1 that men make, so they tend to have less opportunity to spend leisure time at a meetup.
This is a problem, and we can't ask women to simply try harder. They've been trying harder their whole lives. Perhaps it's time for us men to try harder for once.
I have two areas of expertise on this matter. First, I was on UW-Madison's competition-winning FutureTruck team about 10 years ago. We were, IIRC, the only team of about 15 other universities that replaced our competition car's (a Ford Excursion) entire frame with aluminum. In addition to replacing many other steel parts/assemblies with aluminum equivalents, we managed to bring the newly parallel hybrid SUV under stock weight... despite adding a large battery pack and motor. The thing I learned from this experience was: even though aluminum has about 1/3 the density of steel, your parts end up being about 50–55% of the steel weight because you need to add more aluminum to maintain equivalent strength. Basically, given the same tensile strength properties of a part, an aluminum one will be about half as heavy.
Second, I worked as a payload mechanical engineer for a number of spaceflight systems. Suffice to say, our base material for consideration was aluminum. Sure, we deferred to steel for certain applications (e.g., ball bearings, rat cage bars, fasteners, etc) and to myriad materials in others, aluminum was the standard. It has a tremendous strength/weight ratio, can be alloyed in many different ways to get different characteristics, is non-magnetic, is relatively cheap, and can have a number of interesting surface coatings applied. About the only major systemic problem aluminum has is that it is difficult to weld. Not impossible, as my FutureTruck experience tells me, but difficult. It didn't matter to us, though, since NASA generally frowns upon welded joints anyway. Too much strength variation due to heat stress and potential for FOD if not ground properly.
Anyway, I've been waiting for the auto industry to catch up to a bunch of college students for 10 years now. Nice to see one of the Big Four finally getting it. And cheers to the smaller car companies that have been doing it for years.
Since you seem to have some expertise, maybe you can answer this question: Is there a work function difference between steel in contact with aluminum, and does it accelerate corrosion in the steel?
The three main things to be concerned about are corrosion, galvanic corrosion[1] and galling[2].
Corrosion is more commonly known as rust, but that's technically reserved for steel (or, more accurately, iron) oxidation. Aluminum certainly corrodes, but it corrodes into aluminum oxide, or alumina, which is actually a ceramic that is stronger than aluminum. In fact, good luck using aluminum without a coating of alumina... it naturally occurs on the surface of atmospherically exposed aluminum. As a result, when a chunk of aluminum is broken off of a larger piece, the material almost immediately forms a protective layer of alumina. It's almost like aluminum self-heals in the presence of oxygen.
Galvanic corrosion occurs when dissimilar metals come into contact amidst an electrolyte solution. In the case of vehicles, that's usually seawater/sea-mist or salted winter roads. While saltwater is also responsible for accelerating normal corrosion, it also plays a part in galvanic corrosion. So yes, having aluminum and steel touching is a recipe for galvanic corrosion, but galvanic corrosion is not black-and-white. Each metal has an anodic index; a high or low anodic index doesn't matter all that much. What matters is the difference between the anodic indices of the touching metals. For aluminum and steel, that difference is quite small, so galvanic corrosion isn't a huge issue, but it's not negligible either.
Galling occurs when the sliding friction of two parts, say a screw and its threaded mate, results in plastic deformation, usually in the more ductile of the two pieces. This generally doesn't come into play in the construction of a vehicle because many parts are attached either by welding or by a bolt-nut combo. Choosing the correct materials for the bolts and nuts (basically, just use hardened, but not stainless, steel) gets rid of this concern in most cases. In cases where one must screw a steel fastener into a threaded aluminum piece, a helical insert is usually prescribed. While many manufacturers make these, we typically used Helicoil for spaceflight ops because they're tested and rated for spaceflight (batch traceability, proper composition docs, etc).
It's not just Ctrl-[ that does this, Escape does it too. We just typically don't toggle between insert mode / ESC in vim fast enough and enough times to notice it. With the pedal it's quite easy to press and release it a bunch of times before you type anything.
Now that I notice that behavior it is really weird. Anyway, if that is a problem/annoyance for you, then you could try switching to insert-mode by using append ('a') instead, which will bump the cursor up a character and counter ESC bumping you down one.
Is there a way to send data back to the Teensy? That way you could have a program on your computer that tells it "hey, I'm in vim now, so use 'i' and 'Ctrl-['" or "hey, I'm in emacs now, so just be 'Left-Alt' now".
If it's "just a keyboard" and doesn't normally support that, I've seen hacks that utilize the Caps/Scroll/Num lights as inputs back into a keyboard...
I'm not sure if there is a way to send signals back to the device. But, it should be trivial to do what you describe on the operating system level. Ignoring the possibility of specifically looking for that keyboard, you could just have is send obscure keys that you would never type. Then you can just re-map them on the OS level whenever you want to.
A little backstory: this was written the last few days during Startup Weekend Madison, so it's very alpha. Why Startup Weekend? It gave us an excuse to block off the entire weekend and devote ourselves to this project. When we pitched it to the judges, we were highly confident we wouldn't win: we were right. :)
This wasn't created to make any money. It was created so that communities around the world could have their own API of things that matter to them. We welcome contributors! (it's MIT licensed)
While your statements may be true for a larger company, 20% time is working quite well for our consulting company for myriad reasons.
First, of course, there's the opportunity to work on side projects. The only stipulation is that it implicitly (for very loose definitions of implicitly) helps the company. Write open source code, write a blog post, work on your own internal project... but mostly it's been OSS hacking.
Second, it builds slack into our schedule. We (http://bendyworks.com) are a consulting company, and 20% time frees us to "promise" 4 days of work to our clients. And when the inevitable vacation day, sick day or holiday comes up, the client still gets their 4 days of work.
It also lets us push our book club into Friday, which makes it affect our clients' projects even less.
And for a good portion of us, a single day simply isn't enough to satisfy our hunger, so you'll often see a few hanging out at the office, hacking away on the latest clojure, ruby, raspberry pi, or life-hacking project.
I don't think it has that much to do with the size of the company though, but more with the difference between a consulting company and a product company.
In a consulting company, work is time-driven: every hour of work is intended to be billed to a customer. This makes the company very focused on time which makes it easier to dedicate X% of that time to individual's projects. In product companies, work is typically much more result-driven, which makes it more difficult to correctly attribute each worked hour of time to any specific activity. As a consequence, it is much more difficult to do these "X% projects" in part because the X is tricky to correctly measure and attribute.
