Live data from Hacker News

The Misty Programming Language

crockford.com

31–40 of 50 posts

Re: The Misty Programming Language

#31
post #7

Earlier quoted context omitted.

And makes syntax choices (strictness of spacing that forces verbosity) that instantly guarantees that I will never consider the language.

If you choose language based on syntax instead of semantics you miss everything with useful semantics which doesn't happen to use syntax you're familiar with. That seems a terrible loss. E.g. I deeply dislike the syntax of makefiles and xslt, but the declarative model is so good where it fits that it's worth dealing with the visual discomfort.

There are more than enough options that there is rarely a compelling reason to suffer. Useful semantics rarely remains confined.

I spent too much time working with syntax to tolerate one that makes the code more time consuming to read or write (and that includes XSL; I worked a lot with XSL, and I'm not doing it again - if I need its semantics I'll implement something to do it with a less insane syntax).

Re: The Misty Programming Language

#32
post #22

My initial reactions: The good: - network-crossing actor model, but with private addresses and built in routing and security capabilities - object component security - null means null - immutability - AWK-like pattern DSL - functino is a cool way to have your infix operators cake and eat it too as prefix functions The bad: - no type checking on variables, parameters, record fields, record shapes, actor messages, etc…

> - practically need to buy a new keyboard to type all the symbols like '≈', '≠', 'ƒ', etc You just need to configure a Compose key. I encourage everyone to learn how to do this, it opens up a huge character repertoire that can be easily remembered how to type.

This. Although the most ergonomic compose key sequences tend to be assigned to accented characters rather than symbols, so IMO not very convenient for programming.

On Windows I use Capslock (and/or the right Shift key) as a custom-defined modifier to combine with character keys to enter my most frequently used unicode characters for programming personal projects.

Lots of fun characters available for use even when you're dealing with a language where identifiers are limited to ID_Start and ID_Continue (e.g. Javascript), for example:

  ⴵ ⵛ ꘜ ⵣ ꕤ ꖜ 
  ꘖ ꧮ ⴲ ꘖ Ⰴ Ⰺ

Re: The Misty Programming Language

#33

Earlier quoted context omitted.

I think space-style nonsense was a great thing to have up front, because it immediately informed me that I will hate this language and never use it. Genuinely appreciate them saving me time.

I don't get this. Do you purposely 'not' indent your code, to obfuscate it?

I think they share my distaste of languages (like python) that use indentation instead of brackets to signify a code block. People have different preferences and it's totally valid, whatever the reason for those preferences.

Re: The Misty Programming Language

#34
Crockford's RacketCon 2023 talk https://www.youtube.com/watch?v=vMDHpPN_p08 covers Misty (it's apparently specification-only so far) and is generally fun.

Added: couple of previous submissions with a handful of comments https://news.ycombinator.com/item?id=38680087 https://news.ycombinator.com/item?id=38114122

Re: The Misty Programming Language

#35
post #33

Earlier quoted context omitted.

I don't get this. Do you purposely 'not' indent your code, to obfuscate it?

I think they share my distaste of languages (like python) that use indentation instead of brackets to signify a code block. People have different preferences and it's totally valid, whatever the reason for those preferences.

What I don't get is, even if you have brackets, you should be indenting and organizing your code.

It seems like people that fight against indenting must have some bad habits, and are upset that the compiler is enforcing any change.

Like rehab, they have an addiction (sloppy indenting, poor organization), and the compiler is rehab (forcing you to deal with your addiction to give up bad habits).

I do prefer brackets as they are more 'clear'. That doesn't mean different peoples code should have wildly different ways of indenting. We all follow the same traffic rules or it turns into chaos.

Re: The Misty Programming Language

#36
post #33

Earlier quoted context omitted.

I think they share my distaste of languages (like python) that use indentation instead of brackets to signify a code block. People have different preferences and it's totally valid, whatever the reason for those preferences.

What I don't get is, even if you have brackets, you should be indenting and organizing your code. It seems like people that fight against indenting must have some bad habits, and are upset that the compiler is enforcing any change. Like rehab, they have an addiction (sloppy indenting, poor organization), and the compiler is rehab (forcing you to deal with your addiction to give up bad habits). I do prefer brackets as…

Copy-pasting Python code can easily end up in wrong indentation and broken code. Copy-pasting code in bracketed languages usually pastes and then auto-formats that section automatically.

Re: The Misty Programming Language

#37
post #36

Earlier quoted context omitted.

What I don't get is, even if you have brackets, you should be indenting and organizing your code. It seems like people that fight against indenting must have some bad habits, and are upset that the compiler is enforcing any change. Like rehab, they have an addiction (sloppy indenting, poor organization), and the compiler is rehab (forcing you to deal with your addiction to give up bad habits). I do prefer brackets as…

Copy-pasting Python code can easily end up in wrong indentation and broken code. Copy-pasting code in bracketed languages usually pastes and then auto-formats that section automatically.

Sure, but now you're perpetually stuck with the visual noise of unnecessary brackets _all_ the time. Maybe it's because I use vim, but I don't see this use case as terribly important because I can easily reindent with >> and << of a selection.

Re: The Misty Programming Language

#38
post #37
post #36

Earlier quoted context omitted.

Copy-pasting Python code can easily end up in wrong indentation and broken code. Copy-pasting code in bracketed languages usually pastes and then auto-formats that section automatically.

Sure, but now you're perpetually stuck with the visual noise of unnecessary brackets _all_ the time. Maybe it's because I use vim, but I don't see this use case as terribly important because I can easily reindent with >> and << of a selection.

A lot of people prefer the visual noise of { and } to having to manually fix the indentation of code and still having the visual noise of :

Re: The Misty Programming Language

#39

My initial reactions: The good: - network-crossing actor model, but with private addresses and built in routing and security capabilities - object component security - null means null - immutability - AWK-like pattern DSL - functino is a cool way to have your infix operators cake and eat it too as prefix functions The bad: - no type checking on variables, parameters, record fields, record shapes, actor messages, etc…

> symbols like '≈', '≠', 'ƒ' He can not be serious, can he? I thought those were just ligatures. Is he typing on an old APL keyboard?

Other languages that make heavy usage of non-ASCII Unicode characters (such as Lean) often have tooling support such that one can type '\' along with some combination of ASCII characters to generate characters like '≈', '≠' and 'ƒ'. Along with searchable documentation for the whole mapping of shorthand codes to the mapped Unicode values, of course.

Code is read more than written, so I have grown to appreciate programming languages that lean into non-ASCII characters for semantic clarity :)

Re: The Misty Programming Language

#40
There's already a dynamic, general-purpose, transitional, actor language, that I'm a big fanboy of, and that's Elixir.

I don't see anything here that would make me switch from Elixir, especially with its big ecosystem and head start.

Post reply on HN