Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Another go at the Next Big Language

dave.cheney.net

Post reply on HN
Print view View original

41–50 of 125 posts

Re: Another go at the Next Big Language

#41

Post by batista »

jhuni wrote: post #27

If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon. > Rule #1: C-like syntax Just what we need! Another programming language with C-syntax! Its not like we don…

>If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon.

Because you just (presumably) discovered the hammer of Lisp, it doesn't mean anything has to be Lisp like.

Even more so that the supposed superiority of Lisp is mostly anecdotal -- no actual studies on developer productivity, product robustness, etc: all anecdotes.

Where is your PROOF for what you say, computer SCIENTIST?

If anything, empirical data favor languages with C like syntax. More programs we CAN'T DO without have been written in those (from OSs, to office applications, to embedded systems that power almost everything, to servers of all kinds) than in Lisps. In fact, the ratio is incredibly small for Lisp-made world changing programs (Emacs --which is partly C, and then what?).

Re: Another go at the Next Big Language

#42

Post by eckyptang »

batista wrote: post #36

[while checking Yegge's list the NBL should have:] > The final tally is 11 affirmative, 7 negative Yes, but among the negative are items with far most importance than among the affirmative.

I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem:

Perl regex: it covers most perl RE features that are important. The RE engine is the only real weak point I see in Go at the moment but that will change in time and it's "good enough" now.

Strings and streams as collections: String is a collection of runes - you can get the rune at an index fine. The latter is just wrong - A stream is not byte addressable by nature.

Iterators: for not good enough for you? You can build an iterator interface over any type if you desire that but it's really not needed. If it makes you comfortable...

Generics: These are really not needed. This is a common misconception. I've come from a heavy OO C# background (DDD, 1000 class models etc) into Go and I've not missed them for a second. In fact I think I've probably been freed from a million bad design decisions and many refactor sessions.

Standard OOP: I'm not even going down that route. The hacks you have to do to get proper composite models or some level of dynamicity using "standard OO" is horrible. I wish it would go away. CLOS is the nearest thing to something usable - not what C++, Java, C#, PHP force upon everyone.

An there is a cross platform GUI for Go - it's called a web browser.

The only nicety I'd like to see is dynamic loading as it'd allow composite, modular applications to be built without compilation but that has its own pitfalls.

Re: Another go at the Next Big Language

#43

Post by dsymonds »

nyan_sandwich wrote: post #6

I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it. Then I tried to build something. Java-like verbosity. Meh, I can deal with it. []byte and string aren't the same. Whatever, a few extra lines and thot cycles here and there, no big deal. Overly complex library functions. Let me explain this one. In Lua, markdown (discount) is a single function. In Go…

This is the first time I've heard "Java-like verbosity" as a criticism of Go, and I'm baffled by it. Go is generally much more succinct than C++, Java and other similar statically typed languages. Can you expand on your comment?

Re: Another go at the Next Big Language

#44

Post by dsymonds »

ecolak wrote: post #16

It's a pity that we are still talking about things like syntax in the context of a next big language. Programs are still full of bugs, especially concurrent programs, lots of time and effort is still spent on testing. At this day and age, the NBL should be a language that helps or guides a programmer write correct concurrent programs with good performance. It should prevent programmers from making mistakes as much as…

Syntax is very important for a programming language. It's in your face all the time. A serious downside to many programming languages is their awful or inconsistent syntax, and that results in code that is hard to read and comprehend even before trying to understand what the code is doing.

Re: Another go at the Next Big Language

#45

Post by fauigerzigerk »

batista wrote: post #41
jhuni wrote: post #27

If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon. > Rule #1: C-like syntax Just what we need! Another programming language with C-syntax! Its not like we don…

> If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon. Because you just (presumably) discovered the hammer of Lisp, it doesn't mean anything has to be Lisp like…

I would love to see a scientific method to measure developer productivity that isn't ridiculously flawed in completely obvious ways. So far I haven't seen one.

What I care about is primarily what makes me productive. I don't care if it makes anyone else productive but there is a good chance that it might.

Call it proof by induction based on an admittedly shaky prior ;-)

Re: Another go at the Next Big Language

#46

Post by jhuni »

batista wrote: post #41
jhuni wrote: post #27

If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon. > Rule #1: C-like syntax Just what we need! Another programming language with C-syntax! Its not like we don…

> If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon. Because you just (presumably) discovered the hammer of Lisp, it doesn't mean anything has to be Lisp like…

> Because you just (presumably) discovered the hammer of Lisp, it doesn't mean anything has to be Lisp like.

I didn't "just discover the hammer of Lisp", I discovered it quite a while ago and I haven't looked back since. For example, I have been posting Lisp code in this blog for at least a couple of years: http://lisp-ai.blogspot.com/.

> Where is your PROOF for what you say, computer SCIENTIST?

The burden of proof is not on the Lisp community to prove the worth of its fifty year old technology. Lisp outdates C-based languages by at least a decade, so it really should be up to C and the other new languages to prove their worth.

So the burden of proof isn't on me, its up to YOU to prove to me that there is a new language that has advantages over Lisp. And if your designing the "next big language" please prove to me that there is any reason Lispers should be interested in it.

Re: Another go at the Next Big Language

#47

Post by slurgfest »

fauigerzigerk wrote: post #45
batista wrote: post #41

Earlier quoted context omitted.

> If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon. Because you just (presumably) discovered the hammer of Lisp, it doesn't mean anything has to be Lisp like…

I would love to see a scientific method to measure developer productivity that isn't ridiculously flawed in completely obvious ways. So far I haven't seen one. What I care about is primarily what makes me productive. I don't care if it makes anyone else productive but there is a good chance that it might. Call it proof by induction based on an admittedly shaky prior ;-)

Although I agree, I also think some numbers are somewhat better than no numbers. Even in the worst case, at least there is something to argue with other than opinions.

I won't be shocked if data shows that people do better with things they know well and feel happy about, however

Re: Another go at the Next Big Language

#49

Post by tsahyt »

eckyptang wrote: post #42
batista wrote: post #36

[while checking Yegge's list the NBL should have:] > The final tally is 11 affirmative, 7 negative Yes, but among the negative are items with far most importance than among the affirmative.

I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem: Perl regex: it covers most perl RE features that are important. The RE engine is the only real weak point I see in Go at the moment but that will change in time and it's "good enough" now. Strings and streams as collections: String is a collection of runes - you can get the rune at an index fine. Th…

> An there is a cross platform GUI for Go - it's called a web browser.

A web browser is NOT a replacement for a proper GUI library. Writing web GUIs is rather hard in comparison because that was not it's original intention. They're rather slow in comparison because they were not originally intended. The list goes on like this. Everything we did to HTML/CSS/JS in order to "support" those features better of the last decade were just workarounds and things to cover up the fact that we're still dealing with a Markup Language here which is supposed to add semantic meaning to a text or some other piece of information in order to display it.

GUI libraries on the other hand were designed to do GUIs. They're designed not just to display information but to handle user input, handle widgets and components of user interfaces. Most importantly though they're designed to be consistent. Consistency is one of the most important aspects of user interface design and ultimately user experience.

For example, look at Apple: The whole OSX experience and all the apps it comes with are consistent in look and feel. They've got the same polish on top and the same usability features that come with it. That is what takes most of the burden from users. You learn how to use it once and then you're able to apply that knowledge across many other applications. That is how things start to feel "intuitive". That is what all the UX designers are ultimately aiming for.

HTML/CSS/JS enable us to build wildly different GUIs that do their job well but are not consistent for the most part of it. It has enabled designers to go on a rampage, each of them trying to improve on certain aspects. That's good, that's progress but it also comes at a great cost because things stop to feel intuitive and the paradigms of interaction you once learned are rendered invalid. Every site these days is trying to be different to stand out from the crowd and eventually it's all a bloody mess concerning overall UX.

The only real use case for web GUIs are GUIs on the web, not native apps. Introducing the same mess we've got on the web nowadays to native desktop apps is not the right way to do it. A proper GUI library is the way to go both for the developer as well as for the user.

Post reply on HN